Bug 27982

Summary: textfield focus does not work on wikipedia with "Modern" skin
Product: WebKit Reporter: Derk-Jan Hartman <hartman.wiki>
Component: WebKit Misc.Assignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: akeerthi, ap, ayg, b.brachaczek, wenson_hsieh
Priority: P2 Keywords: HasReduction
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
URL: http://en.wikipedia.org/wiki/San_Francisco,_California?useskin=modern
Attachments:
Description Flags
reduced case none

Derk-Jan Hartman
Reported 2009-08-04 07:25:53 PDT
See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=19194 For some reason the searchfield of mediawiki's modern skin does not receive focus when you click on it. It DOES receive focus if explicitly told so through JS or by using an access key (ctrl-alt-f). The links in the same column do work, and this problem is only notable on Webkit browsers, the skin works just fine on all the other browsers. The problem is probably due to "overlapping" content divs or something. If you select the text of the article content, you can notice that the selected text includes all the left margin, overlapping the sidebar that contains the searchfield. P.S. likely this can be fixed in some way in HTML, i'm open for suggestions, but it's still a bug i think.
Attachments
reduced case (4.06 KB, text/html)
2010-02-21 15:13 PST, Derk-Jan Hartman 		no flags
Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Derk-Jan Hartman
Comment 1 2010-02-16 07:02:34 PST
If anyone is EVER gonna look at this, an interesting effect is that when I use the inspector to change the input field (#searchInput) with the WebInspector, from "display:block;" into "display:inline-block", the problem disappears.
Alexey Proskuryakov
Comment 2 2010-02-17 14:47:22 PST
Do you have a reduction that could be attached to this bug?
Derk-Jan Hartman
Comment 3 2010-02-21 15:13:40 PST
Created attachment 49174 [details] reduced case A somewhat reduced case. I suspect this is highly dependent on the negative left margin of the parent div. But the example shows that an input field with "display:block" set in the style cannot be mouse selected, whereas the field with no "display" mode set can be selected for data entry.
Alexey Proskuryakov
Comment 4 2010-02-21 15:22:15 PST
I cannot quite reproduce the problem with this reduction - clicking on "broken" does select it. But drag-selecting is somewhat wrong - when mouse pointer moves past the end of the text to the right, the selection jumps back, as if mouse pointer was moved to the left of text.
Derk-Jan Hartman
Comment 5 2010-02-21 15:32:45 PST
(In reply to comment #4) > I cannot quite reproduce the problem with this reduction - clicking on "broken" > does select it. But drag-selecting is somewhat wrong - when mouse pointer moves > past the end of the text to the right, the selection jumps back, as if mouse > pointer was moved to the left of text. Don't click on broken, click slightly to the right. It seems that when the cursor switches to textmode (as when hovering on the text), selection is possible. This is interesting. I hadn't seen this before, because default values for the Searchbox, are not used on Wikipedia.
Aryeh Gregor
Comment 6 2010-02-21 15:34:26 PST
More minimized test-case: data:text/html, <!doctype html> <div style="height:20em;float:right;margin-left:-15em;width:100%"></div> <input style="display:block"> Every element and style rule there is necessary for the bug to occur, removing any one allows you to click in the <input>. I'm not expert enough at CSS to figure out what's happening here or supposed to happen, but Gecko, Presto, and (I think) Trident all agree here on the opposite behavior from WebKit.
Aryeh Gregor
Comment 7 2010-02-21 16:03:08 PST
A workaround is in MediaWiki as of <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62795>, FWIW, so the Wikipedia link will probably stop exhibiting the problem at some point.
Alexey Proskuryakov
Comment 8 2010-02-21 18:40:50 PST
Thanks for the reductions!
Derk-Jan Hartman
Comment 9 2013-08-28 02:52:50 PDT
I can still reproduce this problem Version 6.0.5 (8536.30.1)
Derk-Jan Hartman
Comment 10 2015-06-30 13:42:24 PDT
This problem can still be triggered with the reduced test case icw Safari 9 seed1.
Derk-Jan Hartman
Comment 11 2020-10-29 06:12:58 PDT
Still a problem in Safari 14
Note You need to log in before you can comment on or make changes to this bug.