HTML5 autofocus attribute is ignored when using an external stylesheet

RESOLVED DUPLICATE of bug 569399

Status

()

Core
Event Handling
RESOLVED DUPLICATE of bug 569399
7 years ago
7 years ago

People

(Reporter: Michael Newton, Unassigned)

Tracking

({html5, testcase})

Trunk
html5, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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>
(Reporter)

Comment 1

7 years ago
Created attachment 478871 [details]
minimal testcase
(Reporter)

Updated

7 years ago
Keywords: html5
Version: unspecified → Trunk
Michael, are you willing to narrow down when this broke?
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression
Created attachment 478883 [details]
testcase (css)
Created attachment 478886 [details]
testcase (html)

Removing @required from the test case and using the CSS file in this bug.
Attachment #478871 - Attachment is obsolete: true
OS: Mac OS X → All
Hardware: x86_64 → All
(Reporter)

Comment 5

7 years ago
(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?
OS: All → Mac OS X
Hardware: All → x86_64
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...
OS: Mac OS X → All
Hardware: x86_64 → All
Fwiw, I don't have that entry in [extensions] and it works fine.  But maybe you need it on Windows?
(Reporter)

Comment 9

7 years ago
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...
Component: DOM: Core & HTML → Event Handling
QA Contact: general → events
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.
(Reporter)

Comment 13

7 years ago
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.
Keywords: testcase
(Reporter)

Comment 15

7 years ago
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).
Keywords: regression
(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 :)

Comment 18

7 years ago
This is a bug, but I don't think it's serious enough to block.
blocking2.0: ? → -

Comment 19

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 569399
You need to log in before you can comment on or make changes to this bug.