User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; NetHelper70; CNS_UA; AD_LOGON=4C47452E4E4554; rv:11.0) like Gecko Steps to reproduce: I use Firefox and go to Yahoo web page. In desktop mode, when zoom in the screen, I can slide the page to see more on the right hand side. But only the lower part of the page can slide. I can not slide the menu bar to see the rest of the bar. Actual results: I can not slide the menu bar. the problem doesn't happen in Chrome. Expected results: I can slide the menu bar.

Can you please post a screenshot? Not sure I understand. Thank you.

This issue reproduce in ATT Homepage.

When zoom in the screen.I can not slide the menu bar.

This issue reproduce in twitter.com(desktop mode)

Mike: Can you offer some input here? This is easiest to see if you pinch zoom in on either the desktop version of Yahoo or the desktop version of start.att.net. On Chrome, the entire page is zoomed, so you can easily move the page around. On Firefox, we seem to zoom the page content and the header separately (very obvious when you zoom) and you can move the content around, but you can't move the header around.

Just to be clear, this issue *only* reproduces when Request Desktop Site is enabled? Here's the header: <div id="mega-uh-wrapper" class="Bds(n) Bdc($headerBdr) Bdbw(1px) T(0) Start(0) End(0) Z(3) Zoom Pos(f)! Scrolling_Bxsh($headerShadow) Scrolling_Bdc($headerBdrScroll) has-scrolled_Bxsh($headerShadow) has-scrolled_Bdc($headerBdrScroll) ua-ie7_Bdbs(s)! ua-ie8_Bdbs(s)! Bgc(#fff) ">....</div> Which has the following rule applied: #atomic .Pos\(f\)\! { position: fixed !important; } So, this is expected behavior for fixed position content, AFAICT. Chrome has magical viewport handling where they always make the viewport scrollable. That said, I'm not sure fixing sites that have Request Desktop Site enabled (where a mobile experience exists) is a high priority for the Fennec team.

(In reply to Mike Taylor [:miketaylr] (55 Regression Engineering Owner) from comment #6) > Just to be clear, this issue *only* reproduces when Request Desktop Site is > enabled? Yes. > Here's the header: > > <div id="mega-uh-wrapper" class="Bds(n) Bdc($headerBdr) Bdbw(1px) T(0) > Start(0) End(0) Z(3) Zoom Pos(f)! Scrolling_Bxsh($headerShadow) > Scrolling_Bdc($headerBdrScroll) has-scrolled_Bxsh($headerShadow) > has-scrolled_Bdc($headerBdrScroll) ua-ie7_Bdbs(s)! ua-ie8_Bdbs(s)! Bgc(#fff) > ">....</div> > > Which has the following rule applied: > > #atomic .Pos\(f\)\! { > position: fixed !important; > } > > So, this is expected behavior for fixed position content, AFAICT. Chrome has > magical viewport handling where they always make the viewport scrollable. Can you provide more detail on that? > That said, I'm not sure fixing sites that have Request Desktop Site enabled > (where a mobile experience exists) is a high priority for the Fennec team. Fair enough.

I think this is basically https://bugzilla.mozilla.org/show_bug.cgi?id=1336292. Karl knows a bit more than me about this, he can provide some more info (if needed).

So basically that's it. Firefox doesn't have the notion of a "visual" or "content" viewport like Chrome does. And some of the issues we have in Webcompat issues are tied to this. At first I thought that Chrome was ignoring the position: fixed or overflow: hidden, but in fact it's because they have this additional virtual viewport based on the content. So this is probably Bug 1123938 It's indeed a major hurdle for users. Agreed with mike that request desktop site on mobile might be expected to break. But on the other hand this is happening also for mobile sites :)

This was fixed by bug 656036.