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

RESOLVED INVALID

Status

defect
--
trivial
RESOLVED INVALID
13 years ago
4 years ago

People

(Reporter: davelentz, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

()

Reporter

Description

13 years ago
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).
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.
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
Reporter

Comment 3

13 years ago
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.
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
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
Assignee: mikepinkerton → english-us
Status: UNCONFIRMED → NEW
Component: Page Layout → English US
Ever confirmed: true
Product: Camino → Tech Evangelism
QA Contact: english-us
Summary: large amount of white space inserted before text → wsj.com - large amount of white space inserted before text in Camino but not Firefox
*** Bug 333931 has been marked as a duplicate of this bug. ***
*** Bug 334998 has been marked as a duplicate of this bug. ***
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

13 years ago
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.


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

Comment 13

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

Comment 14

13 years ago
Same problem with nightly trunk builds of SeaMonkey.

Comment 15

13 years ago
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.
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
Summary: wsj.com - large amount of white space inserted before text in Camino but not Firefox → wsj.com - large amount of white space inserted before text in non-Firefox user agents

Comment 17

13 years ago
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

13 years ago
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.
OS: Mac OS X 10.2 → All
Hardware: Macintosh → All
*** Bug 353718 has been marked as a duplicate of this bug. ***
*** Bug 356329 has been marked as a duplicate of this bug. ***

Comment 21

13 years ago
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. 
(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

12 years ago
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".
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
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

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

Updated

12 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Updated

12 years ago
Duplicate of this bug: 366827

Comment 27

12 years ago
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

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

Updated

12 years ago
Duplicate of this bug: 406491

Updated

11 years ago
Duplicate of this bug: 416433

Comment 31

11 years ago
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.

Updated

11 years ago
Duplicate of this bug: 426767

Comment 33

11 years ago
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.
(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

11 years ago
this is a seamonkey bug. It is still there. It works in FireFox
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.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago5 years ago
Resolution: --- → INVALID
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.