matthew.britton wrote:

(In reply to comment #0)

When I click on the search bar nothing happens. I have to actually click
"search" or "go" and type in whatever I'm searching there.

It's working fine for me. This sounds like an issue with your web browser.

rainman wrote:

Which browser, which username if logged in?

Utahraptorostrommaysorum wrote:

(In reply to comment #2)

Google chrome, and Utahraptorostrommaysi

fryedpeach wrote:

This appears to happen in Modern skin with WebKit browsers. BTW, click to the above "Search" label activates the search field.

Can confirm w/ Safari 4.0.2 and Chrome 3 beta on Mac OS X... looks like it's getting confused when the content area extends vertically below where the search box sits.

• Bug 19670 has been marked as a duplicate of this bug. ***

I filed a webkit bugreport.
https://bugs.webkit.org/show_bug.cgi?id=27982

It's a chromebug indeed. A simple workaround is changing styles for searchInput:

#searchInput {

display:inline;

}

I changed it for WikiKids [1] and everything goes fine now [2]

[1] http://wikikids.wiki.kennisnet.nl/MediaWiki:Modern.css?title=MediaWiki:Modern.css&diff=94726&oldid=91184
[2] http://wikikids.wiki.kennisnet.nl/Hoofdpagina?useskin=modern

lhridley wrote:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/ safari and chrome specific hack /

#searchInput {
    display: inline;
}

}

The above can be added to modern/main.css and it will fix the issue for Chrome and Safari browsers (and any other browser using WebKit) only.

I provided the webkit folks with a reduced case of this problem.

lhridley wrote:

Thanks for the link to the bug report at WebKit. That was filed back in August of last year. Since we have a work-around is there an objection to applying this to modern/main.css and closing this bug?

I consider it to be a hack, but why not. it's not if we can leave all those webkit users out to dry, because the webkit bugzilla isn't used by actual webkit developers....

ayg wrote:

(In reply to comment #11)

Thanks for the link to the bug report at WebKit. That was filed back in August
of last year. Since we have a work-around is there an objection to applying
this to modern/main.css and closing this bug?

IMO, we should just remove the "display: block" from the #searchInput rule in modern/main.css, unless anyone knows of a good reason for it. Monobook doesn't use that, and removing it is sufficient to get rid of the problem.

ayg wrote:

Lisa committed the workaround in r62794, but thedj reported problems with it, and also with the simple display: block removal I suggested. I committed r62795, which removes display: block but also sets an explicit width to work around line-wrapping issues. Marking fixed.

• Bug 22788 has been marked as a duplicate of this bug. ***

According to 22788, .portlet { position: relative; } might work as well. This might be a better solution to the problem...

ayg wrote:

If there's no problem with the current fix, best to leave well enough alone. The status quo ante gave us irregular widths for the search box on different browsers, which we may as well avoid anyway, and avoiding that fixes the problem.

kipmaster wrote:

*** Bug 25478 has been marked as a duplicate of this bug. ***