User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100101 Firefox/4.0b7pre Build Identifier: Autofocus has stopped working in nightly builds, since probably about 7-10 days ago. The problem occurs when a remote stylesheet is specified with a link element. Saving the CSS and calling it locally doesn't have the same effect, nor does putting the CSS directly into the HTML. Reproducible: Always Steps to Reproduce: This very minimal HTML reproduces the problem -- any remote stylesheet triggers it. Removing the link element restores correct behaviour. <!DOCTYPE html> <link rel="stylesheet" href="http://yui.yahooapis.com/2.8.0r4/build/fonts/fonts.css"> <title>Test</title> <input autofocus required>
Michael, are you willing to narrow down when this broke?
Created attachment 478886 [details] testcase (html) Removing @required from the test case and using the CSS file in this bug.
(In reply to comment #2) > Michael, are you willing to narrow down when this broke? I will give it a shot, but "hg pull; hg update; make -f client.mk build" is about the extent of my knowledge in the Mercurial/build department. Do I just do "hg update -r" and pick any revision number from about a week ago? Is http://hg.mozilla.org/mozilla-central/log the best place to look for a revision number or is there an easier place?
Actually, just narrowing it down to the nightly right before it broke and right after will be a good start. If you do want to bisect using local builds in addition, I'd still do the nightly binary search first to get the two revision ids to start bisecting with. Once you have a revision id that works and one that doesn't, you can do: hg bisect -r hg bisect -g good-revision-id hg bisect -b bad-revision-id At this point mercurial will update itself to a revision halfway between the good and bad. Then you make -f client.mk build, test, and if it's good run "hg bisect -g" else run "hg bisect -b". If it fails to compile, run "hg bisect -s" (for "skip"). The end result will be mercurial telling you the first bad changeset (or several if things had to be skipped).
Michael, you will probably have to add "hgext.hbisect=" into "[extensions]" part of your .hgrc file. We definitely need a mdc entry for that...
Fwiw, I don't have that entry in [extensions] and it works fine. But maybe you need it on Windows?
I was actually having trouble getting it to work on any of the nightly builds (Mac 64-bit) I downloaded, going back a couple of months. I usually build my own every few days and I know it was working recently. Currently I have it working in revision 647a515c509b but broken in revision 34f833a4b7d0. I'll narrow it down further.
For what I've been able to see, the autofocus event is correctly sent but the focus is refused to the element. It looks like in CheckIfFocusable(), aContent->GetPrimaryFrame() returns nsnull. Exactly like bug 569399...
So should autofocus cause a layout flush?
Or at least a frame flush. Sure seems like it should. Or frame creation needs to check for autofocus or something.
Sorry, I can't seem to narrow it down at all, it seems very temperamental. I went through the bisect process and ended up at the revision which had been working, but it isn't working now. I couldn't get it working in any of the nightly builds I tried -- about 10 going back to June. Sounds like you all are on the track to figuring it out anyway...
(In reply to comment #13) > Sorry, I can't seem to narrow it down at all, it seems very temperamental. I > went through the bisect process and ended up at the revision which had been > working, but it isn't working now. I couldn't get it working in any of the > nightly builds I tried -- about 10 going back to June. If you have time, could you test if this bug happens with this revision: http://hg.mozilla.org/mozilla-central/rev/13ffec2c6673 It's the revision adding the autofocus feature and I'm wondering if that bug was already there at this point.
I did experience the bug on revision 13ffec2c6673, but as I said I'm having trouble consistently replicating it.
(In reply to comment #15) > I did experience the bug on revision 13ffec2c6673, but as I said I'm having > trouble consistently replicating it. It might be somewhat random but it means that this is not a regression (ie. no commit actually broke that).
(In reply to comment #15) > I did experience the bug on revision 13ffec2c6673, but as I said I'm having > trouble consistently replicating it. Thanks for doing the check by the way :)
This is a bug, but I don't think it's serious enough to block.
I experience this bug in nightly and beta as well. Also on "Intel Mac OS X 10.6". From my point of view this means the feature is (assuming everyone uses external css) not working on (some?) Macs. I can do some more checks on 10.6 systems if necessary.
Marking this bug as a duplicate of bug 569399 given that they seem to have the same origin.