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

https://gerrit.wikimedia.org/r/293884

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

https://gerrit.wikimedia.org/r/293884

The fix can be tested at the reading staging server. For example, http://reading-web-staging.wmflabs.org/w/index.php?title=Lang&mobileaction=toggle_view_mobile

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

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 ✔

@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.

IE9 on Windows 7

Before:

After:

IE10 on Windows 7

Before:

After:

@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 http://reading-web-staging.wmflabs.org/w/load.php?modules=skins.minerva.icons.images&image=mainmenu&format=rasterized&lang=en which is throwing an error unrelated to the patch. Can you confirm?

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: https://phabricator.wikimedia.org/T127233
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> http://reading-web-staging.wmflabs.org/w/load.php?modules=skins.minerva.icons.images&image=mainmenu&format=rasterized&lang=en
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

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.