Page MenuHomePhabricator

Search overlay drops 1px when you type into input
Closed, ResolvedPublic3 Estimated Story Points


Open the search overlay.
Type into the input box at the top.
You'll notice the overlay seems to jump down by 1px.
This impacts both the new search header and the existing search header

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptMay 10 2016, 11:46 PM
Jdlrobson updated the task description. (Show Details)May 10 2016, 11:48 PM
Jdlrobson triaged this task as High priority.May 16 2016, 5:20 PM
Jdlrobson set the point value for this task to 3.May 31 2016, 4:40 PM

3 points because of uncertainty (and the team is new to estimating bugs). Reminder to re-estimate as needed once resolved.

Change 293884 had a related patch set uploaded (by Bmansurov):
Make the search overlay not shift by 1px when a search query is entered

Change 293884 merged by jenkins-bot:
Make the search overlay not shift by 1px when a search query is entered

bmansurov removed bmansurov as the assignee of this task.Jun 13 2016, 12:52 PM
phuedx added a subscriber: phuedx.Jun 13 2016, 2:51 PM

Thanks @bmansurov. I'll take a look now…

phuedx added a comment.EditedJun 13 2016, 3:32 PM

I tested the change on our staging server with the following browsers:

  • OS X El Capitan (10.11.5)
    • Google Chrome (51.0.2704.84) ✔
    • Mozilla Firefox (47.0) ✔
  • Windows 7
    • IE9 ✘
    • IE10 ✔
bmansurov added a comment.EditedJun 13 2016, 4:14 PM

@phuedx I think you've discovered another bug. Would you mind creating a new task?

Edit: What I mean is that fixing the icon placement may fix this issue. Also misplaced icons seem to be a bigger issue than a 1px shift.

phuedx added a comment.EditedJun 13 2016, 4:18 PM

IE9 on Windows 7



IE10 on Windows 7



phuedx added a comment.EditedJun 13 2016, 5:42 PM

@bmansurov: It looks to me if this has caused a regression in IE9 (see T134955#2376646).

@phuedx, are both screenshots from the staging server? It looks to me you're looking at master locally or on production server, but testing the patch on the staging environment. If you inspect the icon and get it's background image, you'll see that it's pointing to which is throwing an error unrelated to the patch. Can you confirm?

phuedx added a subscriber: Tgr.Jun 14 2016, 9:05 AM

Ping @Tgr.

Is the "Sessions are disabled for this entry point" error that we're seeing on our staging server akin to T127233? Since we don't see this error in production, is our server misconfigured?

9:58:14 AM <phuedx> en/en.m work fine but vagrant/labs-vagrant fail
9:58:28 AM <phuedx> something's up with the local sessionmanager config /maybe/
9:58:45 AM <bmansurov> phuedx: ok, i'd like to know the solution too, i'll ask you later once you talk to tgr
9:59:13 AM tgr|away → tgr
9:59:33 AM <phuedx> it looks as if the error is tracked here:
10:00:08 AM <phuedx> ah tgr! speak of the devil and he doth appear :D
10:00:11 AM <phuedx> ;)
10:00:12 AM ⇐ matanya quit (~quassel@wikimedia/matanya) Ping timeout: 276 seconds
10:00:33 AM <tgr> the power of phone notifs
10:00:53 AM <bmansurov> phuedx: i think we have the same problem but different causes, my error message doesn't talk about auth manager
10:00:53 AM <phuedx> TURN THEM OFF
10:00:58 AM <phuedx> THEY ARE EVIL
10:01:08 AM <tgr> give me a sec while I figure out how to scroll on this thing
10:01:15 AM <phuedx> oh good lord
10:01:25 AM <phuedx> it's not that urgent, i'll ping you in the task!
10:01:30 AM <phuedx> go back to whatever you were doing
10:01:31 AM <bmansurov> ok, till later
10:01:37 AM ⇐ bmansurov quit (~bmansurov@wikimedia/bmansurov-wmf)
10:02:00 AM <phuedx> tgr: bmansurov is seeing an error locally that i can reproduce on our staging server
10:02:06 AM <phuedx> the staging server has just been updated
10:02:11 AM <phuedx> sec
10:02:19 AM <phuedx>
10:02:21 AM <tgr> ok, I'll look at it in an hour
10:02:28 AM tgr → tgr|away
10:02:31 AM <phuedx> "sessions are disabled for this entry point"
10:02:44 AM <phuedx> but the error doesn't occur in prod
Tgr added a comment.Jun 14 2016, 11:17 AM

Yes, it means that a request going through some endpoint with MW_NO_SESSION set (currently load.php should be the only one on a Vagrant server; in production also static.php) tries to access the session (most likely by using Message objects and not specifying their language). You should be able to see the full stack trace in exception.log. If you don't see the error in production, then either the code that's causing it has been added recently, or production and the test server are using different code paths (so it could be some difference in e.g. MobileFrontend configuration; core configuration is unlikely to be the cause).

The common cause is using messages in user language (e.g. wfMessage( 'foo' )->parse() will trigger the error, wfMessage( 'foo' )->inContentLanguage()->parse() or wfMessage( 'foo' )->inLanguage( $rlContext->getLanguage() )->parse() won't). Other possibilities are accessing $wgUser or $wgLang, or other equivalent ways of getting those objects.

If you do need a user object, then chances are you are doing something in the ResourceLoaderGetConfigVars hook that should actually be done in MakeGlobalVariablesScript.

phuedx closed this task as Resolved.Jun 14 2016, 3:09 PM
phuedx claimed this task.

After taking a look at both the IE9 case again and @Tgr's comment, I'm alright signing this off.

I'll report an issue for the error that we're seeing – MediaTransformError#__construct invoking Message#escaped without invoking #inLanguage.