Re: [chromium-dev] Link error with chromium on ubuntu 9.10
On Sat, Dec 19, 2009 at 05:03:57PM -0800, n179911 wrote:
Hi,
I get the chromium on ubuntu 9.10. The compilation is okay, but when I get
link, it fails:
$ make -j5 chrome
LINK(target) out/Debug/chrome
collect2: ld terminated with signal 9 [Killed]
make: *** [out/Debug/chrome] Error 1
I think I have 'gold linker' installed:
Building dependency tree
Reading state information... Done
binutils-gold is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 33 not upgraded.
And i have checked I have enough disk space.
Can you please tell me why?
Probably the OOM killer. Chrome takes a very large amount of memory to link.
You can add some swap, or trade a lot of link-time memory for a little startup
delay by building shared. You can do that by putting this in your
~/.gyp/include.gypi:
{'variables': {
'library': 'shared_library',
}}
Good luck, -- Jacob
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on // NOLINT?
On Thu, Dec 10, 2009 at 11:14:32AM -0800, Scott Hess wrote: On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote: On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org wrote: In essence: return DoWork(foo) #if defined(OS_POSIX) DoWork(posix_specific) #endif ; // -- Lint complains about this guy I'd prefer this: #if defined(OS_POSIX) return DoWork(foo) DoWork(posix_specific); #else return DoWork(foo); #endif The same number of lines, but much easier to read. Or: bool ret = DoWork(foo); #if defined(OS_POSIX) ret = ret DoWork(posix_specific); #endif return ret; Breaking a single statement up with a macro is icky. If something extra in an expression is a common case, I've sometimes seen it done like: return DoWork(foo) POSIX_ONLY( DoWork(posix_specific)); where POSIX_ONLY will expand to nothing or its argument. It's ugly, but compact. -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 12:05:55PM -0800, Evan Martin wrote: On Fri, Nov 20, 2009 at 4:23 AM, rahul rahulsin...@gmail.com wrote: I was trying to compile chromium today on Linux and I got this error. This error occurred because of -Werror CFLAG set in the Makefile. I remedied by writing a one-liner to delete all occurrences of -Werror from CFLAGS in all Makefiles. However, this error intrigued me. I saw through the code and the classes in question have declared virtual methods but haven't declared a destructor. In that case, the compiler generates the destructor. Base *b = new Sub(); delete b; To the best of my knowledge, if Base is the class which defines virtual methods but non-virtual destructor, delete can cause a memory leak if Sub happens to be taking more memory than Base. I think that the destructor for a class with virtual methods has either to be public virtual or protected non-virtual for the proper freeing of memory. Would someone help me clarify this? I know there might be some scenarios where this can be done intentionally but looks like there are more arguments for adding a virtual destructor than not adding one. I see that this is done for the Delegates. Also, if this is one of the intended special cases, can someone explain how to compile chromium then? Deleting -Werror from CFLAGS is an ugly hack at best. Your analysis is correct. However, a virtual destructor is not needed in the case where you never delete through the Base*. It turns out for our codebase that is very common (due to lots of observer-like patterns), so we decided to not rely on this compiler warning. It's only caused horrible bugs once or twice! :) The correct fix would be to disable this particular warning in build/common.gypi. However, I'm puzzled why nobody else has encountered the problem you're mentioning. Can you provide some details about your compiler, system configuration, etc.? I encountered this, by turning on -Wextra which included -Wnon-virtual-dtor, and submitted some patches to clean it up, which were rejected. (So, add on -Wno-non-virtual-dtor to get a build.) -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 02:47:56PM -0800, Peter Kasting wrote: On Fri, Nov 20, 2009 at 1:31 PM, James Robinson jam...@google.com wrote: What's the benefit of omitting the virtual destructor? I'm not trying to say it has massive benefits. I'm trying to make concrete the rather abstract statement that we have patterns right now where objects don't specify destructors. If you want me to argue for it, then I would probably say that it's a little simpler and clearer without a destructor, and for someone used to reading our code it's a tipoff that this is an instance of the interface class pattern. If I were to add a destructor, I'd declare one in private as opposed to adding a virtual one, again just to emphasize that this is an interface as opposed to a parent of more specialized children. Not a very important set of reasons. If you feel violently, write the patch. I won't stop you. Ahem? http://codereview.chromium.org/201100/show -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote: On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson ja...@mandelson.orgwrote: http://codereview.chromium.org/201100/show Yes, that caused a large subsequent discussion at which it seemed like it was determined that this was fine. I was surprised to hear this issue come up again because I'd assumed you'd already checked in your fixes. I had the impression that at the end of the discussion you were still against. Can you LG 201100 and 200106 ? -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: chrome build problem on Ubuntu
On Tue, Oct 20, 2009 at 05:47:08PM -0700, webinfinite wrote: I am building Chromium on my Ubuntu box but have the following errors: /usr/bin/ld: skipping incompatible /home/yezhang/chrome/chromium_zhang/ src/sconsbuild/Debug/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status scons: *** [/home/yezhang/chrome/chromium_zhang/src/sconsbuild/Debug/ chrome] Error 1 scons: building terminated because of errors. You're on x86_64, right? There's a build bug on that arch where chrome proper and nacl pick different build architectures or something like that. You can work around it by setting the envvar GYP_DEFINES to target_arch=ia32 or target_arch=x64 so they don't try to pick an arch themselves. You'll have to run gclient runhooks to rebuild the scons files from gyp. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter craig.schlen...@gmail.com wrote: [big snip] This problem only seems to happen with the scons shared build. The make build does not have this problem so there seems to be something different about how the dependencies are being generated with the make versus scons gyp backends. I'm now getting build failures for linux_page_load_uitest with the shared object build, under both scons and make: /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' ... and a bunch of other DevToolsManager:: undefined references. (32-bit, Debug. Giving 32-bit Release a spin now.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Mon, Oct 12, 2009 at 06:29:02PM -0700, Lei Zhang wrote: Maybe you need to clobber? The shared build bot on the FYI waterfall is working: http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 gclient runhooks regenerated a bunch of .mk's, but I'm still getting the same link error. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Mon, Oct 05, 2009 at 10:20:47AM -0700, Steven Knight wrote: The variable name is actually just 'library'. The default is set in build/common.gypi. You can either change the default variable right in build/common.gypi or set the environment variable GYP_DEFINES=library=shared_library to get a shared library build. (I have it modified locally in one of my checked-out Linux trees for periodic sanity checks that Linux at least nominally builds with shared libraries. IIRC, a lot of the Linux folks use shared library builds regularly, for the much faster link times.) I tried this, and it does indeed link far, far faster! However, I got errors about RegisterInternalNaClPlugin(): /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so: undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))' (Also one for libbrowser.so) I see these are protected by #ifndef DISABLE_NACL and if (command_line.HasSwitch(switches::kInternalNaCl)), but why would that affect things? DISABLE_NACL should be defined or not the same for shared or static build, and the HasSwitch is a run-time check. If I comment them out, then chrome links. But the call is in RenderProcess::RenderProcess(), surely not dead code that the static link would be removing. Any idea what's going on here? -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int,
int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
on -Wno-strict-aliasing, and it landed back in
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
Running gclient runhooks had no effect here.
Building with --verbose shows the very long link line attached, which
has [nN][aA][cC][lL] only in -lnacl.
gclient revinfo begins with
src: http://src.chromium.org/svn/trunk/s...@28154;
(Simpler way to get this?)
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
flock
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/linker.lock
g++ -o
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so
-L/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-Wl,-rpath=/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-pthread -m32 -shared -pthread -m32
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/automation/dom_automation_controller.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/bindings_utils.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/event_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/extension_process_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/js_only_v8_extensions.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/renderer_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/loadtimes_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/media/audio_renderer_impl.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_master.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_queue.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/about_handler.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/audio_message_filter.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer
[chromium-dev] Re: [Linux] How did I just fix the build?
On Sat, Oct 03, 2009 at 04:25:08PM -0700, Peter Kasting wrote: On Sat, Oct 3, 2009 at 11:59 AM, Antoine Labour pi...@google.com wrote: On Sat, Oct 3, 2009 at 11:09 AM, Dan Kegel d...@kegel.com wrote: On Sat, Oct 3, 2009 at 11:07 AM, Dan Kegel d...@kegel.com wrote: undefined reference to BlockedPopupContainer::kImpossibleNumberOfPopups Aha. It's a bug in our code. chrome/browser/blocked_popup_container.cc needs to follow through and actually declare storage for that variable. MSVC and GCC differ regarding the C++ spec for when you define a static const in a class. The spec says you need to provide storage for it. You're missing the point. The pre-existing code already had the existing declarations and usage for this variable. I didn't touch that at all. I added a DCHECK that referred to it in a function that already referred to it, and things broke. I commented out the DCHECK and left all the other references and things worked again. This puzzles me. The other references are all in arithmetic expressions, so I presume they get the variable access converted to using its immediate value, and don't reference the variable anymore by link time. But DCHECK_NE expands to CheckNEImpl, which takes its arguments by reference, so now the variable has to actually exist (have storage). (I guess CheckNEImpl's inline isn't kicking in, or if it is, the compiler isn't following the reference-dereference to see it can just use the immediate value.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 02:45:21PM -0700, Ben Laurie wrote: On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. Ah, I see. Hmmm. The Linux send(2) man page explicitly says the message is all-or-nothing, and the SUS entry seems to indicate the same thing, though not as clearly, so that framing protocol can probably just be [lengthdata]* Still more complicated than having the socket layer do it though. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 03:48:02PM -0700, Adam Langley wrote: On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: The Linux send(2) man page explicitly says the message is all-or-nothing, I don't think so. It says: If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted. I think the confusion is that the underlying protocol for SOCK_STREAM isn't atomic. The description of the error is clearer: EMSGSIZE: The socket type requires that message be sent atomically, and the size of the message to be sent made this impossible. It also says: When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-block‐ ing I/O mode. In non-blocking mode it would return EAGAIN in this case. Which reads like all or nothing to me, though I could imagine a (perverse?) implementation with each writer having a send buffer lower layer pulling data from multiple writers' send buffers in an interleaved manner. (But maybe there's something else which restricts sockets to a single send buffer.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] gclient sync failing with 405 Method Not Allowed
Recent attempts to run gclient sync have been failing with: running 'svn update /usr/local/google/home/jlm/chrome/home/chrome-svn/tarball/chromium/src/third_party/WebKit --revision 27313' in '/usr/local/google/home/jlm/chrome/home/chrome-svn/tarball/chromium' svn: Server sent unexpected return value (405 Method Not Allowed) in response to PROPFIND request for '/repository/webkit/trunk/WebKit/chromium' Error: failed to run command: svn update /usr/local/google/home/jlm/chrome/home/chrome-svn/tarball/chromium/src/third_party/WebKit --revision 27313 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient sync failing with 405 Method Not Allowed
On Wed, Sep 30, 2009 at 11:39:24AM -0700, Yaar Schnitman wrote: This is probably related to: http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba Ahh yes, that fixed it, thanks. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 04:37:46PM -0700, Jeremy Orlow wrote: On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote: I'm guessing different people/companies will have different needs for a kiosk mode. Maybe all of these should be separate flags rather than one kiosk flag? We could then offer recommendations in a Chromium for kiosks Wiki page? I think the reasoning for allowing this feature is that some minority would find it helpful and it wouldn't hurt much. I'm concerned that it is getting much too complicated. I think we shouldn't do it if it is going to be this complicated. Would multiple command line flags rather than one really complicate the design? Mohamed's original patch was just a bunch of if statements keying off of one flag. Seems like the same amount of work to have each if statement key off of a different one. Or am I missing something? If nothing else, it grows the configuration space. Supporting a kiosk mode seems like a good idea. Supporting 2^N different flavors of kiosk mode sounds dicier. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
On Sat, Sep 26, 2009 at 11:40:07AM -0400, Mohamed Mansour wrote: Hi all, (need UI team feedback and other keyboard guru's) We need a more coherent story for accessing various toolbars. The current toolbars that exist right now are: - Toolbar - Bookmark bar - Extension bar - More in the future Currently ALT + SHIFT + T brings your focus to the toolbar, but there is no way to get to the others. This blocks keyboard users accessing the other bars which is kind of annoying if your a keyboard user. According to Jonas Klink (Accessibility guru) he said that shortcut was only a temporary solution and would like to get rid of it and replace it with something more generic. So we need to think of a uniform access solution to all these toolbars. [...] Maybe we could treat them akin to menus, and have Alt-SomeLetter go move the active focus to the bar? Alt-T and Alt-B seem unbound, but Alt-E (and not Alt-D) opens the Document menu. Alt-F opens the Wrench menu. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Add Jank to appropriate bugs
On Tue, Sep 15, 2009 at 04:28:41PM -0700, Peter Kasting wrote: Tomorrow afternoon a couple of us will be triaging all bugs with the Jank label. Jankiness is sluggishness in the UI, so things like slow startup or shutdown, tabs taking a while to paint or to close, keyboard accelerators and button clicks being unresponsive, and other similar Chrome doesn't do what I tell it to, when I tell it to bugs are all Jank. In preparation for this triage, please add this label to applicable bugs you've filed or are following. If you know bugs that should have this added but don't have the ability to change them yourself, send me an email with the bug numbers and I'll take a look. This will ensure we don't miss any issues in our triage. When I find web pages which demonstrate an exceptional amount of chrome jank, is there a particular bug I should add them to? Or should we wait for the general jank-tagged issues to get resolved? -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
