This bug is reproducible under a strange set of conditions. It's in the Safari 5.0.2 release. If a form has `autofocus` on an input, the focus rings do not display on that page and autofill does not happen as long as: - The page has an external style sheet (`<link>` or `@import`) - You did not visit the page directly from a link (the bug *does* appear after a reload or navigating to the URL manually) - You did not visit the page using the back button. The bug goes away the first time you mouse down on a button or link. See the URL for a demo.
Forgot to mention: because the bug doesn't reproduce on a page visited from a link, reload the demo page to see it in action.
Created attachment 72317 [details] Self-contained demonstration of the bug. I think I have come across the same bug, but in another form. The stylesheet does not need to be external. Not only does the focus-ring not show, but hidden elements, that you try to show using javascript, doesn't get displayed, before you hover over an element that has a :hover pseudoclass style. I have made an example that is self-contained and doesn't use an external stylesheet.
This was also reported as http://crbug.com/69607, and has a possibly better test-case at http://bolinfest.com/webkit/chrome8bug.html. Also cc-ing the author of autofocus support (from http://trac.webkit.org/changeset/34626).
http://crbug.com/65695 also looks the same issue. Style recalc or repainting is blocked?
(In reply to comment #4) > Style recalc or repainting is blocked? I found :focus style is not applied to the element with autofocus. Document::recalcStyle() is called after setFocusedNode(), but CSSStyleSelector::SelectorChecker::checkOneSelector() for the element is not called.
ok, probably I understand. When an external stylesheet is linked or a sub-tree with autofocus is shown, an input element with autofocus is attached in Element::recalcStyle(). HTMLFormControlElement::attach() calls focus(), and focus() tries to call recalcStyle() to apply :focus style, but the latter recalStyle() is skipped because we are already in recalcStyle().
Created attachment 79569 [details] Patch
It seems wrong to need an extra message loop cycle to get this right.
Here is another test case for this bug: http://test.vervestudios.co/test.html To reproduced the bug in Webkit: 1. Focus your browser's address bar and press enter. 2. Hover over any button to see that its background-color will not change. 3. Try clicking a button. Hm, the style doesn't change. 4. Press F5 5. Now try hovering over a button. Viola! It works. so does clicking it. So, what triggers this bug? - An external stylesheet (even if it is empty). - An input[type=text] (or just <input>) with the [autofocus] attribute - A button - Both the text-input and button need to be inside the same containing element (and <body> won't trigger the bug) Some interesting stuff: - The buttons' onclick, onmouseover, etc. events are fired even when bug is present. - If you use javascript to edit a className the styles won't update. - In certain circumstances, if you hover over an anchor link the bug disappears. I haven't been able to reproduce this in a reduced test-case. (corresponding bug ion webkit's bug-tracker says that the anchor needs a :hover style...I haven't tried it though)
Created attachment 82969 [details] Patch
Attachment 82969 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1 Source/WebCore/html/HTMLFormControlElement.cpp:125: Declaration has space between type name and * in HTMLFormControlElement *control [whitespace/declaration] [3] Source/WebCore/html/HTMLFormControlElement.cpp:147: One line control clauses should not use braces. [whitespace/braces] [4] Source/WebCore/ChangeLog:9: Line contains tab character. [whitespace/tab] [5] Total errors found: 3 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 82970 [details] Fixed webkit coding style.
I don't know why it is failing to apply in efl-ews bot.
fatal: Unable to create '/mnt/eflews/git/webkit/.git/index.lock': File exists. Looks like the efl ews bot has a git lock problem. I wouldn't worry about it.
Comment on attachment 82970 [details] Fixed webkit coding style. queuePostAttachCallback() looks better. However I shouldn't set review+ because the patch is based on my code :-D
Comment on attachment 82970 [details] Fixed webkit coding style. View in context: https://bugs.webkit.org/attachment.cgi?id=82970&action=review > Source/WebCore/html/HTMLFormControlElement.cpp:146 > + queuePostAttachCallback(updateAutoFocusCallback, this); post attach callbacks are the work of the devil! :(
(In reply to comment #16) > (From update of attachment 82970 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=82970&action=review > > > Source/WebCore/html/HTMLFormControlElement.cpp:146 > > + queuePostAttachCallback(updateAutoFocusCallback, this); > > post attach callbacks are the work of the devil! :( Thank you for the comment. I will come up with another solution. But can you please help me understand why it is not advisable to use queuePostAttachCallback? I would like to learn so that I don't repeat this in the future.
*** Bug 55063 has been marked as a duplicate of this bug. ***
*** Bug 57431 has been marked as a duplicate of this bug. ***
According to Bug 57431, this autofocus problem causes a crash. Raise to P1.
This was fixed by another similar patch in another bug. https://trac.webkit.org/changeset/86976
"Self-contained demonstration of the bug." still does not work properly. Is that the same bug or a different one?
(In reply to comment #22) > "Self-contained demonstration of the bug." still does not work properly. Is that the same bug or a different one? I worked on Google Chrome 13.0.782.1 (WebKit r87771).
(In reply to comment #23) > (In reply to comment #22) > > "Self-contained demonstration of the bug." still does not work properly. Is that the same bug or a different one? > > I worked on Google Chrome 13.0.782.1 (WebKit r87771). Oh. Brain fart, I was in Chrome 11 (r86024). Looking good here too! Thanks :) .