330575 - wsj.com - large amount of white space inserted before text in non-Firefox user agents

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: English US, defect)

Description

[Dave Lentz]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060313 Camino/1.0.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060313 Camino/1.0.0+

Here's how to reproduce the problem:
1) open WSJ base url [http://online.wsj.com/home/us]
2) pick any article, click on title to open it
3) article renders OK, and at the conclusion of rendering page, a large chunk of white space is inserted at the top of the article

Additional info:
1) If you click of the "print" link on the page, the reformatted article does not display this behavior
2) Firefox 1.5.01 does not behave this way, nor does Safari, but both Camino 1.0 and recent nightly builds do exhibit this behavior
3) WSJ just revamped their page layout -- this has only started since that point.  Clearly, there is something in their html (and in the html differences between the article layout and the article print layout) that triggers this behavior in Camino
4) the amount of white space inserted seems to be just enough to push the text offscreen, so that one must page forward to see it.  I suppose it's possible this is just a coincidence, but it raises my coincidence-alert monitors.

Reproducible: Always

Steps to Reproduce:
1) open WSJ base url [http://online.wsj.com/home/us]
2) pick any article, click on title to open it
3) article renders OK, and at the conclusion of rendering page, a large chunk of white space is inserted at the top of the article

Actual Results:  
large chunk of white space in inserted at the front of the rendered article at the conclusion of rendering

Expected Results:  
the article should display as rendered, up to the point at which the white space is inserted

1) If you click of the "print" link on the page, the reformatted article does not display this behavior

2) Firefox 1.5.01 does not behave this way, nor does Safari, but both Camino 1.0 and recent nightly builds do exhibit this behavior

3) WSJ just revamped their page layout -- this has only started since that point in time.  Clearly, there is something in their html (and in the html differences between the article layout and the article print layout) that triggers this behavior in Camino and only in Camino.

4) the amount of white space inserted seems to be just enough to push the text offscreen, so that one must page forward to see it.  I suppose it's possible this is just a coincidence, but it raises my coincidence-alert monitors.

I'm running OS X 10.4.5 (current), and this behavior is reproducible across 3 different machines (Powermac dual G5, iBook G4, iMac G4 LCD).

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Dave, can you try two things for me to see if the white space disappears?

1) Try the page with ad-blocking off if you have it on - we've seen a couple of cases recently where something we block causes something else to end up inexplicably and wildly out of position

2) Try spoofing your UA as Firefox to see if WSJ is sending the wrong JS or other content to Camino.

Comment 2

[Chris Lawson (gone)]

Every time I've seen this lately it's been the latter problem as mentioned in comment 1. This is probably TE if anything.

cl

Comment 3

[Dave Lentz]

OK, I tried the things Smokey suggested, and damned if spoofing the browser as Firefox didn't fix it.  Turning off ad-blocking did nothing.

So what's the right thing to do here, bug the WSJ to fix their browser determination javascript to encompass Camino (and what's the best way to nicely ask so as to have some chance of them actually fixing their code?), or just to accept this and run Camino under the Firefox flag?

The way I see it, there's 2 answers here -- the "right" answer and the "easy" answer.

Comment 4

[Chris Lawson (gone)]

The right answer is option 1.

The easy answer is option 2.

This should probably be kicked to TE. I've been seeing this a lot lately; I wonder if there's a new CMS out there that's doing it.

cl

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Dave, if there's some sort of webmaster contact address, you can send an email telling them "Gecko is Gecko" ;)  IOW, if they qualify their site for Firefox 1.5 (which uses Gecko 1.8), then any other browser using Gecko 1.8 will work exactly as Firefox 1.5 does--and they should send the same JS/CSS/HTML/etc. to all Gecko 1.8 user-agents.

(We should look to see if MDC has an updated document on perils of UA sniffing and how to do it right if you absolutely need to do it, i.e., Gecko is Gecko.  If not, it might be worth seeing if we can get some Gecko devs to write up a "Gecko is Gecko" document everyone can point bad sites to.  As Chris noted, we're starting to see a lot of "sniffing for Firefox only and sending something close but broken to Camino".)

-> Tech Evangelism

Comment 6

[Chris Lawson (gone)]

*** Bug 333931 has been marked as a duplicate of this bug. ***

Comment 7

[Samuel Sidler (old account; do not CC)]

*** Bug 334998 has been marked as a duplicate of this bug. ***

Comment 8

[Chris Lawson (gone)]

Latest update, from someone on the forum who contacted the WSJ:

"Thank you for your email message. We apologize for the delay in response. We are not able to support that browser as it is still a beta (test) browser. For Macs, we highly recommend you use the Safari or Firefox browsers to access our site."

/me bangs head on desk

cl

Comment 9

[gene c]

Same problem on linux builds - i.e. not just mac os.

Currently Problem is visible with this build (bon echo)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060501 BonEcho/2.0a1 ID:2006050105

I tried using user agent switcher but it had no effect selecting any of the 3 windows XP default choices.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 336385 has been marked as a duplicate of this bug. ***

Comment 11

[Chris Lawson (gone)]

*** Bug 339431 has been marked as a duplicate of this bug. ***

Comment 12

[Chris Lawson (gone)]

*** Bug 343813 has been marked as a duplicate of this bug. ***

Comment 13

[Andrew Schultz]

*** Bug 347795 has been marked as a duplicate of this bug. ***

Comment 14

[Tom Kloos]

Same problem with nightly trunk builds of SeaMonkey.

Comment 15

[Tom Kloos]

This most annoying problem (but obviously has a workaround -- scroll down) is NOT exhibited by current released versions of Opera, IE, or Firefox.  It also seems to be related somehow to the presence of advertising using Flash in the side columns. I'm using Seamonkey on Win XP Pro so it's not Mac OS or platform specific.

Comment 16

[Chris Lawson (gone)]

The reason SeaMonkey users are seeing this now is the same reason it's always been for anyone -- the WSJ is sniffing user-agent identifiers by browser name, not by rendering engine.

If they change their sniffer to look for a specific Gecko revision, this problem will go away for ALL users of Gecko browsers. (I'll bet this is a problem with the latest trunk builds of Firefox too.)

To the two people who just commented about this being a problem with SeaMonkey, please e-mail the WSJ and tell them about the problem, and point them to this bug. This has been a problem for FAR too long.

cl

Comment 17

[gbastin]

Wrote the WSJ, and got the following back: "Thank you for your email message.  We are unable to support the Linux operating system, but we have heard from subscribers that do use it that our site works best with the latest Firefox browser from Mozilla.  The other two browser suites cited in your letter do have issues with our site, and not just for Linux users."  The other two browsers I mentioned were SeaMonkey 1.0.4 and Mozilla 1.7.13.

Comment 18

[Felix Miata]

They had this to say to an OS/2 SeaMonkey user:

Our technical staff is aware that the Seamonkey browser does not work
with the site. Seamonkey is an ongoing development project with Mozilla.
It is not expected to be completed in the near future. For that reason,
the technical staff recommends that you use the Firefox browser.

Someone needs to give WSJ a large dose of clue stick.

Comment 19

[froodian (Ian Leue)]

*** Bug 353718 has been marked as a duplicate of this bug. ***

Comment 20

[Samuel Sidler (old account; do not CC)]

*** Bug 356329 has been marked as a duplicate of this bug. ***

Comment 21

[Tim Richardson]

On Windows XP with this client:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0

I do not have the WSJ bug.

But I do under Linux. 

Comment 22

[Chris Lawson (gone)]

(In reply to comment #21)
> On Windows XP with this client:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003
> Firefox/2.0
> 
> I do not have the WSJ bug.

That's because the above user-agent contains the word "Firefox".

cl

Comment 23

[Steffen Wilberg]

WFM with Minefield, which is a Firefox trunk build without "Firefox" in the user agent string.
I entered www.wsj.com and got redirected to http://online.wsj.com/public/us, then clicked on an article. It shows me a "FREE PREVIEW" without "a large chunk of white space at the top of the article".

Comment 24

[Chris Lawson (gone)]

Can someone with a WSJ account please confirm this with Camino? I highly doubt the WSJ has actually done anything to fix this.

Comment 25

[Robert Baertsch]

Yes, it is still a problem with Camino Version 2007022813 (1.0.4) and Mac OSX 10.4.10.

Comment 27

[Tim Richardson]

I use iceweasel on Debian (with adblock plus). Using the extension user-agent-switcher I changed iceweasel to firefox and the white space problem immediately disappeared. Thanks for the tip, such an annoying problem fixed so easily.

this is the working user-agent string: 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071004 Firefox/2.0.0.8 (Debian-2.0.0.8-1)

so this is clearly a wsj problem. I have sent them an email explaining it (i'm a subscriber) with a link to this bug report.

Comment 28

[James Rome]

I sent the same stuff to the WSJ months ago with NO response. They don't care.

Comment 31

[Stuart Morgan]

Since they list email addresses for execs for the online version on their site, I sent a couple of them a formal (to the extent that an email is formal) complaint email on behalf of the Camino project a few days ago. We'll see if management at WSJ cares any more about pointlessly aggravating their users than the support/feedback people there apparently do.

I'm guessing the answer is no, but it was worth a shot.

Comment 33

[Julius]

I believe this problem has been resolved. Would someone else confirm? I read WSJ.com daily and noticed a few days ago that the articles now layout correctly (before I would have to scroll down to read the article). I am using 3.0RC2.

Comment 34

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #33)
> I am using 3.0RC2.

That has a "Firefox" user-agent, so it won't trigger the bad WSJ behavior.

Comment 35

[James Rome]

this is a seamonkey bug. It is still there. It works in FireFox

Comment 36

[Karl Dubost💡 :karlcow]

This bug has not moved for the last 6 years. I'm closing it. WSJ has probably changed design a few times. If there is more analysis with exhibit of an issue, please open a new bug or give new information on this one.