Bug 27982 - textfield focus does not work on wikipedia with "Modern" skin
Summary: textfield focus does not work on wikipedia with "Modern" skin
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://en.wikipedia.org/wiki/San_Fran...
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2009-08-04 07:25 PDT by Derk-Jan Hartman
Modified: 2020-10-29 09:55 PDT (History)
5 users (show)

See Also:


Attachments
reduced case (4.06 KB, text/html)
2010-02-21 15:13 PST, Derk-Jan Hartman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Derk-Jan Hartman 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.
Comment 1 Derk-Jan Hartman 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.
Comment 2 Alexey Proskuryakov 2010-02-17 14:47:22 PST
Do you have a reduction that could be attached to this bug?
Comment 3 Derk-Jan Hartman 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.
Comment 4 Alexey Proskuryakov 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.
Comment 5 Derk-Jan Hartman 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.
Comment 6 Aryeh Gregor 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.
Comment 7 Aryeh Gregor 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.
Comment 8 Alexey Proskuryakov 2010-02-21 18:40:50 PST
Thanks for the reductions!
Comment 9 Derk-Jan Hartman 2013-08-28 02:52:50 PDT
I can still reproduce this problem Version 6.0.5 (8536.30.1)
Comment 10 Derk-Jan Hartman 2015-06-30 13:42:24 PDT
This problem can still be triggered with the reduced test case icw Safari 9 seed1.
Comment 11 Derk-Jan Hartman 2020-10-29 06:12:58 PDT
Still a problem in Safari 14