If a heuristic can judge the accuracy, then this readbility mode could
be offered as a hint in some part of the screen (top or bottom right,
similar to popup blocker does/used to do?).
Otherwise there is an option for a fallback solution. Look at Aardvark
(firefox plugin,
This morning's Mac build is a train wreck :( Every tab crashes while loading.
[52334:19459:1323448372606907:ERROR:/Users/pinkerton/src/trunk/src/chrome/common/ipc_channel_posix.cc(611)]
pipe error: Bad file descriptor
I think I'd personally prefer the other page elements to remain in place,
but have their brightness dimmed down (the way Youtube/Hulu/etc. have a
turn down the lights feature - perhaps this is what Mike meant by
lightboxes?). For this to work well it would probably also have to stop
running flash
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching the tree go red after it.
Appreciation from another time zone,
-- dean
On Thu, Mar 5,
I didn't mean that to be such a personal flame, we need to have some
better guards to prevent this from happening. It's just frustrating
when the tree is broken for hours at a time. It's happened a lot
lately, the tree has been closed and/or hosed for the majority of my
workday week. The
There is one thing though, I don't think hclam checkin turned any Linux
tests red. The linux build was unusable, but the unit tests and layout tests
were passing. It seems like there is a lack of tests here.
When I woke up I reverted his change because it broke Purify on windows and
another unit
On Thu, Mar 5, 2009 at 6:01 PM, Nicolas Sylvain nsylv...@chromium.org wrote:
There is one thing though, I don't think hclam checkin turned any Linux
tests red. The linux build was unusable, but the unit tests and layout tests
were passing. It seems like there is a lack of tests here.
Yeah, we
On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote:
everytime I do a checkin I do a sync and send it
to the try server, which really takes me a lot of time, but still try server
is showing me green light to check in, am I suppose to not trust the try
server and rely
On Thu, Mar 5, 2009 at 7:03 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote:
2009/3/5 Amanda Walker ama...@chromium.org
On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com
wrote:
everytime I do a checkin I do a sync and send it
to the try server, which really takes
I looked at yesterday Alpha's try run on linux, the try server runs ui
tests and it was green. The mac try slave were dead last evening. I
would only blame poor testing on linux side.
I'm adding ui testprinting tests on modules mac linux on next master restart.
And oh, please read the 3 lines
About 2: I was just faced with the same problem in another project on
my job. And it turned out that Visual Studio doesn't create *.lib file
if there's no functions declared with __declspec(dllexport) or
mentioned in *.def file in the project. Nothing to export from dll -
no *.lib required. ;-)
The definition of what the accesskey modifier is the result of
EventHandler::accessKeyModifiers(). On Windows it's
althttp://trac.webkit.org/browser/trunk/WebCore/page/win/EventHandlerWin.cpp,
and on Chromium it's also
It sounds like they only use the single modifier when the
accessibility system setting is turned on, otherwise they use the dual
one. Why don't we just do the same thing? I'm pretty sure we should
match the platform default browser instead of emacs.
-Ben
On Thu, Mar 5, 2009 at 1:22 PM, Avi
And when I build WebKit and run it in Safari, only ctrl+alt work. Weird. I'm
doing testing now to see what this fixes.
Avi
On Thu, Mar 5, 2009 at 4:38 PM, Avi Drissman a...@google.com wrote:
That value gets set in WebKit's WebFrame.mm:
if ([[NSApp
If you don't do the merges, you can stop reading now -- though you
might ask yourself why you're not doing the merges. They are so much
fun.
In the next few days (hopefully not weeks), I am making changes to
InspectorController in an effort to unfork it. This is the good news.
The bad news is
Hello Plugin Gurus
The following link is very well written and I hope it still holds good
http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture
I have some followup questions on plugin development (internal)
1. Based on the plugin architecture design
Mohamed,
I'm glad to see your interest in tackling this problem.
Unfortunately, that data is collected under an agreement between the user
and Google, so we cannot share the dumps. It's OK to share the stack traces,
which have no personally identifying information, but I'm not sure we can
even
I suspect this is like crashes due to memory corruption: It won't do much
good to stare at the call stack at the time corruption was detected; we need
to know the stack at the time corruption occurred (assuming this is Chrome
that is corrupting the profile).
For memory corruptions we have gflags;
18 matches
Mail list logo
