User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060823 BonEcho/2.0b2 Build Identifier: Keys for 'Filter' and 'Show all' don't work in Firefox 2.0b, either English or localized. TB is fine though. Reproducible: Always

I see this on Linux too. It does work if I use Shift though so I think this is a consequence of bug 340902. Setting ui.key.contentAccess to 4 fixes it so I'm guessing about:config is "content" not "chrome". I'm not sure what the about: URLs are supposed to be.

> so I'm guessing about:config is "content" not "chrome". The patch for bug 340902 uses the docshell type to differentiate, so it doesn't matter what the document is, but rather where it's loaded. Anything loaded in a tab content area is content as far as that patch is concerned.

The about:config window is considered to be content, and as such accesskeys in there work using ALT+SHIFT+ instead of ALT+.

Clearing blocking-firefox2 request.

(In reply to comment #3) > The about:config window is considered to be content But I have an almost complete patch that fixes this bug. I'm using nsContentUtils::IsChromeDoc() instead of using the docshell, which is what I think Boris hinted at in comment 2...

Do users of accesskeys generally think about the system principal of the document they are interacting with, or do they think like docshell - "if it's below the tabstrip and above the statusbar, it's content"? Having about:config use content accesskeys would be a win, since we wouldn't need to use the world's worst accesskey letter on "F_i_lter" to avoid collisions with chrome - are there other chrome documents displayed in tabs, where it wouldn't be a good thing?

(In reply to comment #6) > "if it's below the tabstrip and above the statusbar, it's content"? So now the Find box is content too ;-) I think most users recognise about:config as a builtin function, should they ever come across it.

(In reply to comment #7) > I think most users recognise about:config as a builtin function, should they > ever come across it. Apart from the fact that there's probably no study confirming or denying this and that about:config isn't really supported UI anyway, I'd still distinguish between what is always accessible (the chrome - including the Find bar) and what happens currently to be displayed. Having the same accesskey modifier for both will lead to accessibility issues one way or the other (and which of the l10n teams really checks for about:config's accesskeys not being present in the UI?). So to make life easier, I'd not make an exception for "chrome" content - rather display about:config (which seems to be the only exception) in it's own window as Thunderbird does. Finally, it should take an extension author only minor hackery to have content at individual URIs react to the chrome accesskey modifiers (by automatically setting the above mentioned prefs when tabs are switched and on focus/blur).

(In reply to comment #6) > Having about:config use content accesskeys would be a win, since we wouldn't > need to use the world's worst accesskey letter on "F_i_lter" to avoid > collisions with chrome No, it wouldn't be win. Collisions is not an argument to use a new modifier for a particular document, because to the *user* the access modifier is a *desktop wide* property. The browser UI needs to be consistent with that. The exception (introduced by bug 340902) for ordinary web pages has its pros and cons but I think we agree that a separate modifier was needed. (In reply to comment #8) > Finally, it should take an extension author only minor hackery to have content > at individual URIs react to the chrome accesskey modifiers (by automatically > setting the above mentioned prefs when tabs are switched and on focus/blur). > That sounds very fragile. If they really have that need then we should probably make the access modifier a property of the document or docshell or something. But extension UI is generally chrome isn't it? (and thus part of the browser UI and should use the same access modifier.) If it's "browser UI" then use Accel. If it's a "web page" then use Shift+Accel. Let's not make it more complicated than that. I want the user to know *instinctively* what key combo to press when they see an underlined letter.

It wasn't possible to use nsContentUtils::IsChromeDoc() from accessible/ because of link dependencies, so I had to hack my own. It would be good to have a nsIDocument::IsChrome() method instead, but that's a bit late for the branch I guess. This patch needs to go on the 1.8 branch too.

I'm still not clear on why you are so certain that users (once they hear about Alt+Shift+ and know it makes a difference) will know that the web page about:config isn't like the web page file:///c:/whatever or the web page http://whatever I'd say we needed ui-review from our UI guru, but he already weighed in by closing the bug as invalid...

(In reply to comment #11) > I'm still not clear on why you are so certain that users (once they hear about > Alt+Shift+ and know it makes a difference) will know that the web page > about:config isn't like the web page file:///c:/whatever or the web page > http://whatever I think it's pretty obvious that about:config is part of the browser UI and not an arbitrary web page - conceptually there is no difference between about:config and the Preference dialog. If we think a user (which actually knows of about:config) does not realize this then I'd say we need to remove/redesign about:config, perhaps by opening it in a new window as was suggested. The only eveidence we have so far is that this was actually reported as a bug, not much perhaps, but perhaps an indication...

This will not block the release. I'll come back to comment on the UI issues in a moment.

(In reply to comment #12) > The only eveidence we have so far is that this was actually reported as > a bug, not much perhaps, but perhaps an indication... The reason for reporting this was that current Dutch (NL) 2.0 builds share the A key with Bookmarks in main bar, which for FF 1.5 and when using ALT+ makes the latter useless when in about:config as Show all gets precedence. Thus, for 2.0 it looked like the one for about:config wasn't functioning at all, until I read comment 3. Let me add that I had never even heard of the ALT+SHIFT+ combo, despite using NS/Moz products since the early days of their existence. That may be because ALT+ worked too until recently, but as Mats put it above it's probably by instinct as well - I see no difference with any other UI part.

I'm sympathetic to this bug but honestly, it doesn't make a whole lot of sense to me to vary the access key UI based solely on what principal the document has. What we really want to test is "is this part of the browser application UI, or not?" Content vs chrome docshells is a pretty good approximation to that. In this case however we have a content docshell that is really part of the application UI. So what I suggest, in lieu of a better suggestion, is that we have a new document flag to indicate "I am really part of the application UI even if hosted in a content docshell", and set that flag for chrome: and about: documents, and test it when choosing the access key.

Or we could fix this crap of loading parts of the UI in content docshells. In my opinion, typing about:config in the URL bar should create a non-content <xul:browser> (or new window or whatever you want) and load it in there. As in, it should be loaded in a chrome docshell. If we do that for the very few about: pages that need chrome privs, we can neuter chrome privs in content docshells in general, thus fixing several security attack vectors. I know I've proposed this before, and got no response...

Sounds good to me.

Comment on attachment 235414 [details] [diff] [review] Patch rev. 1 Canceling requests due to comments 15 to 17.

Is comment 16 (don't load about:config in content docshell) likely to be fixed here, or should that be a separate bug with [sg:want] in the status whiteboard?

(In reply to comment #6) > Do users of accesskeys generally think about the system principal of the > document they are interacting with, or do they think like docshell - "if it's > below the tabstrip and above the statusbar, it's content"? I don't know about "most users" -- and I don't think use of content vs. chrome accesskeys is an easy question to levy statistics on. All I can say is how I reason (I belive I'm a typical user but I could be mistaken): if it's below the tab bar and above the status bar, it's "content". If it's part of the "browser decorations", it's chrome. Isn't that the criterion which distinguishes beween use of userChrome.css and of userContent.css? > Having about:config use content accesskeys would be a win, since we wouldn't > need to use the world's worst accesskey letter on "F_i_lter" to avoid > collisions with chrome - are there other chrome documents displayed in tabs, > where it wouldn't be a good thing? > IIUC, any chrome document can be displayed in a tab by typing its chrome-protocol URI in the Location Bar. There are extensions (useful ones IMHO) which open the Download Manager and the Addons Manager in tabs. Some Internet errors cause the opening of a XUL error page in the tab where the error occurred. Are about-protocol pages "chrome documents"? Anyway, they are meant to be displayed in tabs (if at all).

> Isn't that the criterion which distinguishes beween use of userChrome.css and > of userContent.css? No. It's not. That decision is made based on the docshell type. While at the moment all docshells tabbrowser creates are content dochells, there have been thoughts about changing that behavior, for security reasons. > IIUC, any chrome document can be displayed in a tab That's not supported, though. And there have been thoughts on disabling it, for security reasons. > Some Internet errors cause the opening of a XUL error page in the tab Let's not confuse "XUL" and "chrome". The two are not the same. > Anyway, they are meant to be displayed in tabs (if at all). It's not clear that they are, in fact. about: can be displayed either in a tab or as a dialog. There have been suggestions that things like about:config should never be loaded in tabs but should open a separate window, for security reasons.

I think that this bug is now reproduced all UIs which are loaded in tab such as addon manager and session restore.

I can confirm that this bug affects Session restore tab. Also I believe that Bug 880728 can be marked as duplicate of this bug.

(In reply to Mats Palmgren (:mats) from comment #9) > (In reply to comment #6) > > Having about:config use content accesskeys would be a win, since we wouldn't > > need to use the world's worst accesskey letter on "F_i_lter" to avoid > > collisions with chrome > > No, it wouldn't be win. Collisions is not an argument to use a new modifier > for a particular document, because to the *user* the access modifier is a > *desktop wide* property. The browser UI needs to be consistent with that. > The exception (introduced by bug 340902) for ordinary web pages has its > pros and cons but I think we agree that a separate modifier was needed. Collisions very much are an argument here. We'd need to avoid them by picking keys that aren't already taken by some surrounding browser chrome, including transient stuff like the find bar, notification bars, side bars, dev tools etc. This is complicated by the fact that some pages like about:config and about:addons live in toolkit/, not browser/, and therefore can't cater exclusively for Firefox and its access keys; this is pretty close to the problem that made us pick a different modifier for web content. I also agree with the previous comments pointing out that from the users perspective, the content area remains the content area regardless of the document type, which is essentially an implementation detail and not even consistent across all about: pages (e.g. about:credits is remote web content).