1323062 - Wall Street Journal shows desktop site on mobile

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Mike Kaply [:mkaply]]

http://www.wsj.com/

Navigates to the desktop version.

We should evangelize (or figure out if it is something we are doing).

Comment 1

[Mike Kaply [:mkaply]]

Doesn't appear to be using user agent detection, as changing UA to Chrome doesn't help.

Comment 2

[Mike Taylor [:miketaylr]]

(moving to TE, since we use this product for software dev junk)

Comment 3

[Mike Taylor [:miketaylr]]

Karl, can you take a look? This might be related to viewport stuff.

Comment 4

[Mike Taylor [:miketaylr]]

<meta name="viewport" content="initial-scale=1.0001, minimum-scale=1.0001, maximum-scale=1.0001, user-scalable=no" data-reactid=".0.0.3">

Comment 5

[Mike Taylor [:miketaylr]]

Dennis, can you take a look -- I forgot Karl is on PTO this week. This site is important to a partner.

We need to check if they're sending the same responsive design to us and to Chrome Mobile, and if so, is this our viewport bug?

Comment 6

[Mike Taylor [:miketaylr]]

(oops)

Comment 7

[Eric Tsai (no more review request accepted)]

I use MITM proxy and change the viewport to 

  <meta name="viewport" content="initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=no" data-reactid=".0.0.3"/>

Then it looks good for me now.

Comment 8

[Eric Tsai (no more review request accepted)]

A better approach for workaround iOS9 can use shrink-to-fit:

  <meta name="viewport" content="width=device-width, initial-scale=1, min-scale=1, max-scale=1, shrink-to-fit=no">

Comment 9

[Mike Kaply [:mkaply]]

Why do we behave differently than Chrome?

Comment 10

[Dennis Schubert [:denschub]]

Yeah, this is weird. I can confirm all of Erics observations (thanks for that!), if we replace 1.0001 by 1, the site works fine. This seems to be another edge case of Fennec viewport definitions. 1.0001 is used to workaround an issue in iOS9, and as Eric also mentioned, shrink-to-fit=no is a much better workaround. We should probably get them to use shrink-to-fit=no then.

Mike, to we have a direct contact to the WSJ developers? Setting it to needscontact.

> Why do we behave differently than Chrome?

Very fair question. The short version is: viewports are a mess. There are a lot of edge cases like initial-scale=0 that never got speced and behave different across browsers. We're in the process of investigating differences between the implementations, building an actual specification out of our results (see [0]) and getting "the correct behavior" implemented in Fennec. That being said, the work on this started recently and there is not much to report yet. Karl will hopefully work on this soon! :)

[0]: https://github.com/whatwg/compat/issues/62

Comment 11

[Mike Kaply [:mkaply]]

> Mike, to we have a direct contact to the WSJ developers? Setting it to needscontact.

Not with developers, but I think we can get in through some content/ad contacts.

Can you put together an email and I can have it forwarded it along?

The contact us section here:

https://customercenter.wsj.com/public/view/contactinformation.html

Seems to be for website problems as well.

Comment 12

[Mike Taylor [:miketaylr]]

(Karl may have WSJ contacts from the past.)

Comment 13

[Mike Taylor [:miketaylr]]

And.... maybe we should clamp 1.0001 to 1 in Gecko for viewport values? I wonder at what point we would not want to clamp though...

Comment 14

[Karl Dubost💡 :karlcow]

Philip Camacho might have contacts.
https://www.linkedin.com/in/philipcamacho
http://twitter.com/MozWebCompat/status/810658407732559872

We had as a contact in the past Bifur Zaleski. But not sure he is around now.
https://bugzilla.mozilla.org/user_profile?login=bifur%40zaleski.net

Comment 15

[Mike Kaply [:mkaply]]

Can someone post exactly what a note to WSJ would look like? We have contacts in BizDev.

I need a "You should fix this and this is why"

As a side note, do we know of other sites that have this problem? Should we fix it on our end?

Comment 16

[Mike Taylor [:miketaylr]]

(In reply to Mike Kaply [:mkaply] from comment #15)
> Can someone post exactly what a note to WSJ would look like? We have
> contacts in BizDev.
> 
> I need a "You should fix this and this is why"

Not sure exactly what you're looking for in terms of a note beyond explaining that the site looks broken in Fennec due to a workaround for a Safari bug, and providing the suggested fix (that doesn't regress their Safari issue). Comment #8 has the suggested fix. 

> As a side note, do we know of other sites that have this problem? Should we
> fix it on our end?

Yeah, we should. Karl, do we have a bug open for viewport bugs? If not, can we get one (or more) filed?

Comment 17

[Karl Dubost💡 :karlcow]

Mike (Kaply),
do not hesitate to give my contact information to WSJ if they need further help with the issue.

About clamping the value for the meta viewport, see. 
Bug 1313264

Comment 18

[Eric Tsai (no more review request accepted)]

:mkaply for scale=1.0001, http://www.walmart.ca have this problem. 

You can refer to https://webcompat.com/issues/3498 
But as Thomas' diagnosis result, this only fix portrait mode, landscape mode still have problem.

Comment 19

[Mike Kaply [:mkaply]]

So based on Eric's last comment, does the shrink-to-fit option not work for landscape and portrait?

So we actually don't have a fix?

Comment 20

[Eric Tsai (no more review request accepted)]

Attachment: walmart_ca_landscape_with_fix.png

Comment 21

[Eric Tsai (no more review request accepted)]

:mkaply, for my test on Z3C, this fix works for wsj.com and walmart.ca on both landscape/portrait mode

Comment 22

[Mike Taylor [:miketaylr]]

(In reply to Mike Kaply [:mkaply] from comment #19)
> So based on Eric's last comment, does the shrink-to-fit option not work for
> landscape and portrait?
> 
> So we actually don't have a fix?

shrink-to-fit is an iOS only meta viewport value, currently, and fixes the problem the site devs were trying to solve. The fix suggested by Eric undoes the iOS hack, adds the correct iOS fix, and unbreaks Fennec, AFAICT.

Comment 23

[Thomas Wisniewski]

Actually, I somehow missed Eric's shrink-to-fit suggestion. I just re-tested with it, and a local copy of the site seems to work fine for me on my Android phones in portrait and landscape orientation, so it might be the way to go (I don't have an iOS device to test with, though, so I can't confirm if it works on those).

Comment 24

[Mike Kaply [:mkaply]]

> And.... maybe we should clamp 1.0001 to 1 in Gecko for viewport values? I wonder at what point we would not want to clamp though...

Did we decide if we are going to do this? Do we know how common this hack is?

Our WSJ contacts aren't coming back at all.

Comment 25

[Mike Kaply [:mkaply]]

I've contacted WSJ through their site and supposedly it got forwarded on. We'll see.

Comment 26

[Mike Kaply [:mkaply]]

So come to find out bug 1313264 is something different. It's clamping the lower bound, not rounding.

I've looked at Chromium

https://cs.chromium.org/chromium/src/ios/web/web_state/page_viewport_state.mm?type=cs&q=maximum-scale+package:%5Echromium$&l=62

And I don't see them turning 1.0001 into 1. The parse it as a double.

So this must have something to do with us treating 1.0001 differently...

Comment 27

[Karl Dubost💡 :karlcow]

Mike (Kapl)(In reply to Mike Kaply [:mkaply] from comment #26)
> So come to find out bug 1313264 is something different. It's clamping the
> lower bound, not rounding.
> 
> I've looked at Chromium
> 
> https://cs.chromium.org/chromium/src/ios/web/web_state/page_viewport_state.
> mm?type=cs&q=maximum-scale+package:%5Echromium$&l=62
> 
> And I don't see them turning 1.0001 into 1. The parse it as a double.
> 
> So this must have something to do with us treating 1.0001 differently...


On WebKit, I always wonder if it was happening here.
https://github.com/WebKit/webkit/blob/04c2bea6721a142bb73f9626e646c5aa5251c2d8/Source/WebKit2/Shared/CoordinatedGraphics/SimpleViewportController.cpp#L118-L145

Comment 29

[Karl Dubost💡 :karlcow]

I'm changing the dependency on this issue because there is the specific Bug 1469747 for 1.0001 values.

Comment 30

[Hiroyuki Ikezoe (:hiro)]

I'd like to confirm whether bug 1494422 fixed this or not.  But I can't see the desktop versions on Firefox 62 in the first place.  Am I missing something, or the site has been already changed?
Karl?

Comment 31

[Karl Dubost💡 :karlcow]

Yes they changed the site since. I guess Mike Kaply contact was effective.
https://bugzilla.mozilla.org/show_bug.cgi?id=1323062#c25

Right now:
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">


Walmart.ca has still a 1.0001 viewport style.
<meta name="viewport" content="width=device-width, initial-scale=1.0001, minimum-scale=1.0001, maximum-scale=1.0001, user-scalable=no">

https://www.walmart.ca/en And it's currently working on 64.0a1 (2018-10-21) (64-bit) 
* Desktop with RDM + Firefox Android UA.
* Android device.

Comment 32

[Karl Dubost💡 :karlcow]

I'm changing this as fixed as the site has changed.