713074 - Microsoft.com does not render correctly on Fennec Native, but renders correctly on Webkit

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[John Hopkins (:jhopkins)]

Web page or screen you were on when you saw the issue: 

Steps to reproduce:
1. Open http://microsoft.com in Aurora.  Note the narrow, vertical rendering of the web page in the middle of the screen.
2. Open Aurora's menu and click Request Desktop Site.

What you expected: 

Desktop-like rendering of microsoft.com

Actual:

Narrow, vertical rendering of website.

Comment 1

[Aaron Train [:aaronmt]]

X-UA-Compatible: IE=EmulateIE7

curl -A "Mozilla/5.0 (Android; Linux armv7l; rv:11.0a1) Gecko/20111222 Firefox/11.0a1 Fennec/11.0a1" -I microsoft.com -L
HTTP/1.1 301 Moved Permanently
Connection: close
Date: Thu, 22 Dec 2011 20:49:15 GMT
Server: Microsoft-IIS/6.0
P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI'
X-UA-Compatible: IE=EmulateIE7
X-Powered-By: ASP.NET
Location: http://www.microsoft.com
Content-Length: 23
Content-Type: text/html
Cache-control: private

Comment 2

[Jason Smith [:jsmith]]

Pulling up Microsoft.com side by side with the UA changed to IPhone against the Stock Browser, it looks like the slideshow isn't rendering correctly on my galaxy nexus for fennec native with the UA changed. On a galaxy S2, only a third of the actual site is used as real estate for rendering on the page.

Comment 3

[Jet Villegas (inactive)]

Need some more info here. Why is it busted? -ms CSS without -moz? Broken DOM API? See bug 668218 for a better way to report bugs like this.

Comment 4

[Jason Smith [:jsmith]]

Attachment: Microsoft Source Code

Comment 5

[Jason Smith [:jsmith]]

I don't think it's a problem in the CSS spectrum - There's no evidence of use of prefixes on microsoft's mobile site.

Comment 6

[Jason Smith [:jsmith]]

For comment 5, I meant to say - I don't think it's problem in the CSS prefixes spectrum (a prefixes specific issue).

Comment 7

[Jet Villegas (inactive)]

This site is hard-wired to be 320 pixels wide:

body {max-width:320px; width:320px; font-family:Helvetica, Arial, 'sans-serif'; margin:0 auto; padding:0; font-size:11px; direction:ltr;}

The Galaxy S2 has 480 x 800 pixels.

Comment 8

[Jason Smith [:jsmith]]

Knowing that this is not a CSS-prefixes problem, it no longer depends on bug 739832.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Jet Villegas (:jet) from comment #7)
> This site is hard-wired to be 320 pixels wide:
> 
> body {max-width:320px; width:320px; font-family:Helvetica, Arial,
> 'sans-serif'; margin:0 auto; padding:0; font-size:11px; direction:ltr;}
> 
> The Galaxy S2 has 480 x 800 pixels.

Right. Knowing this, an important to question ask is - Why does it render the correct size still on webkit, but on gecko, the width properties appear to be followed?

Comment 10

[Jason Smith [:jsmith]]

Clarify on comment 9 - Why is the correct size rendered correctly on webkit even with those CSS width properties in place, but on gecko, the width properties appear to be followed? My guess is there is something being detected on CSS parser that is not being picked up on gecko.

Comment 11

[Jason Smith [:jsmith]]

I don't think this is an evangelism problem after doing the deep dive. Sounds like there might be a layout problem here.

Comment 12

[Jason Smith [:jsmith]]

Testing on a Galaxy Nexus vs. Galaxy S2 - Looks like Gecko always sticks strictly to the width and max-width properties no matter what. Webkit appears to be changing though. It's almost like we're not observing some property that overrides the body width enforcement. Going to check this on Opera as well.

Comment 13

[Wesley Johnston (:wesj)]

The site being sent to us is not the site being sent to the stock Android browser. If I had to guess, I'd say we're getting the Windows Mobile (not Windows Mobile 7, old skool WinMo) version of the site, which is designed to work in old school mobile IE on screens that apparently never were much more than 320px wide.

The one that is sent to the Android stock browser contains a meta-viewport that tells them how to scale it for the screen. Since it doesn't tell us anything, we treat it as a desktop site and scale it to 800px (I think?, maybe 980px) wide.

Comment 14

[Jason Smith [:jsmith]]

Nice catch Wesley. Didn't catch that at first glance. Just confirmed this by switching to the IPhone UA on Fennec Native Nightly - This is a user agent sniffing problem that pulling up an old site. Moving back to Fennec Native --> Evangelism.

Comment 15

[Aaron Train [:aaronmt]]

As of May 28th, I am getting a Mobile Microsoft site which is functioning pretty well. Marking this resolved WFM.

Comment 16

[Jason Smith [:jsmith]]

(In reply to Aaron Train [:aaronmt] from comment #15)
> As of May 28th, I am getting a Mobile Microsoft site which is functioning
> pretty well. Marking this resolved WFM.

Reopening. I'm still getting the problem identified in comment 13, causing the mobile microsoft site to look bad on a galaxy nexus.

Comment 17

[JP Rosevear [:jpr]]

Looking at this, the stock browser on ICS actually forces you to scroll horizontally to see the content, I think we actually do a better job rendering.

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to JP Rosevear [:jpr] from comment #17)
> Looking at this, the stock browser on ICS actually forces you to scroll
> horizontally to see the content, I think we actually do a better job
> rendering.

microsoft.com renders correctly (no scroll) for me on Android Stock on ICS on a Galaxy S2. As originally reported, only the middle third of the screen is used in Fennec Beta. Seems to work well on Fennec Beta if you zoom in manually.

Comment 19

[Kev Needham [:kev]]

Just wanted to note that we did this kind of evangelism last year when the UA was changed, and the suite rendered it properly. It appears that the incorrect rendering was a result of a change we made (where Fennec/x.y was dropped). We've asked MS to look at it, but it'd be great if we stopped mucking with the UA. 

Every time we do, stuff is going to break, and this is the kind of change that should have been advertised well in advance vs. post-implementation.

Comment 20

[Lawrence Mandel [:lmandel] (use needinfo)]

Kev, completely agree. We should include the B2G UA when discussing these changes with MS this time around. Unfortunately the UA is not finalized. However, if MS can avoid sniffing for "Android" and instead focus on "mobile" we should be good in both cases.

Comment 21

[Jason Smith [:jsmith]]

Microsoft appears to be rendering a responsive design webpage now that does not sniff the user agent for either FF Android or webkit. No UA sniffing or site problems evident anymore. Closing.

Comment 22

[Aaron Train [:aaronmt]]

Verified via Nexus 7