Ton [:Tonnes] Reporter
	Description • 18 years ago

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

	Mats Palmgren (inactive)
	Comment 1 • 18 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 18 years ago

> 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.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 3 • 18 years ago

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

	Reed Loden [:reed]
	Comment 4 • 18 years ago

Clearing blocking-firefox2 request.

	Mats Palmgren (inactive)
	Comment 5 • 18 years ago

(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...

	Phil Ringnalda (:philor)
	Comment 6 • 18 years ago

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?

	Mats Palmgren (inactive)
	Comment 7 • 18 years ago

(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.

	Simon Bünzli
	Comment 8 • 18 years ago

(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).

	Mats Palmgren (inactive)
	Comment 9 • 18 years ago

(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.

	Mats Palmgren (inactive)
	Comment 10 • 18 years ago

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.

	Phil Ringnalda (:philor)
	Comment 11 • 18 years ago

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...

	Mats Palmgren (inactive)
	Comment 12 • 18 years ago

(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...

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 13 • 18 years ago

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

	Ton [:Tonnes] Reporter
	Comment 14 • 18 years ago

(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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 15 • 18 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 16 • 18 years ago

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...

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 17 • 18 years ago

Sounds good to me.

	Simon Bünzli
	Comment 18 • 18 years ago

Comment on attachment 235414 [details] [diff] [review]
Patch rev. 1

Canceling requests due to comments 15 to 17.

	Jesse Ruderman
	Comment 19 • 17 years ago

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?

	Tony Mechelynck [:tonymec]
	Comment 20 • 17 years ago

(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).

	Boris Zbarsky [:bzbarsky]
	Comment 21 • 17 years ago

> 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.  

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)
	Comment 23 • 12 years ago

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

	Ruvim Pinka
	Comment 24 • 10 years ago

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

	Dão Gottwald [:dao]
	Comment 26 • 10 years ago

(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).