Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0 and the equivalent Linux build
1) go to: http://www.mozilla.org/quality/browser/front-end/testcases/wallet/login.html
2) enter a username and password (no worries, it a bogus login form)
3) dismiss the Password notification bar with any of the choices.
4) click the Back button to return to the test log-in page
focus can't be put into any of the form fields. The search mozilla field is also not focusable. The focus seems to be stuck on the "Login" button
expected results: the form fields should be focusable
work-around: reload the log-in page
I'm not able to reproduce on WinXP rc1builld
I filed under Password Manager because if you don't dismiss the Notification bar, the bug doesn't exist.
withdraws nomination. it is present in beta5. haven't checked further back.
Password manager isn't itself involved, something wonky is going on between the notification bar widget and the form controls. If it's not in XP, I'll guess this is a cocoa widget problem.
Note that a workaround is to click in some other window (or the desktop), and then in the browser again. The form controls behave properly then.
I can also reproduce this by:
0) Enable privacy.popups.showBrowserMessage
1) Go to Google. Search for "popup test"
2) Visit first site
3) Run one of the tests, get a notification bar
4) Click back a few time to get back to google
5) Search field doesn't work.
Regression window is between the builds 080115_04 and 080116_04.
Check-ins within this time frame: http://tinyurl.com/3uq7jj
I can reproduce on Linux (FC7) Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9) Gecko/2008051202 Firefox/3.0
a cocoa bug in that case?
Lets move it to core:widget.
nominating for rc1 relnote on mac systems.
Like already mentioned, no problem on windowsXP. Could this be a regression from bug 402505?
(In reply to comment #8)
> Like already mentioned, no problem on windowsXP. Could this be a regression
> from bug 402505?
Mmh the patch on this bug only changed files for Mac, but as Tracy said in comment 5 it's also reproducible on Linux. So it should be caused by another check-in?
Tony, due to above information the relnote should also be added for Linux systems.
Hmm, perhaps this is a regression from bug 399852 then?
Argh, sorry for the spam, that patch was backed out immediately after.
Does Linux have the same regression range?
(In reply to comment #12)
> Does Linux have the same regression range?
Aleksej, would it possible for you to have a look here?
Can we get someone to look at this? Aleksej, any work here? We're saying this is a known issue in Firefox 3 and it'd be great to fix it so we can remove that issue. ;)
Sorry, seems like I've missed that message.
The bug starts appearing between 2007083104…2007090104, together with the feature.
Also, the problem disappears if you put a focus there using Tab.
We'll take this on branch if it's important enough to fix in mozilla-central.
roc or vlad: Can one of you assign this to someone? Seems like a pretty annoying accessibility issue and it has a regression range (see comment 15).
According to comment #15 the regression range for Linux is different from the regression range for Mac, so we're actually looking at two different bugs here. Maybe Josh could look at the Mac side of it.
Tracy the URL isn't available anymore. Were the testcases moved to another location? For now I'm not able to reproduce this issue on other sites even with the given builds given in comment 4. It would be great to have an URL where this focus bug can still be reproduced.
Thanks for the update of the URL. I tried again and had to notice that my given regression range from comment 4 is wrong. Sorry. Now the regression starts between these two builds on OS X:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011804 Minefield/3.0b3pre
Check-ins within this time frame: http://tinyurl.com/3rs74k
Bug 403232 could be a good candidate for the OS X part. CC'ing Steven who created the patch on bug 403232.
(In reply to comment #20)
> Bug 403232 could be a good candidate for the OS X part. CC'ing
> Steven who created the patch on bug 403232.
I've confirmed your regression range, Henrik. But I suspect that my
fix for bug 403232 just unmasked another bug -- one that already
existed by the time my patch landed.
I will try to reconfirm the Linux regression range, and look there to
see what I can find.
> I will try to reconfirm the Linux regression range, and look there
> to see what I can find.
I've confirmed Aleksej's Linux regression range from comment #15, and
I agree with him that the most likely trigger was the patch for bug
226735 ("replace modal pre-submit save password dialog with
But (aside from reversing that patch completely) I can't find any part
of it, the reversing of which triggers this bug. (I tried reversing
parts or all of the part of the patch that applies to
browser/base/content/browser.js ... but had no luck. No other part of
the patch (taken by itself) seems likely to make a difference.)
But I suspect that the problem (whatever it is) has to do with what
happens when the "post-submit bar" is dismissed (after pressing one of
its buttons). Maybe Gecko views/frames aren't being focused or
unfocused properly when that happens.
What makes me wonder is that it is working now with GranParadiso/3.0.4pre ID:2008100504 but not with Minefield/3.1b1pre ID:20081006021501 on OS X. I should have a check if it is related to any pref or add-on (still two different profiles).