bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

washingtonpost.com - Does not display search box properly

RESOLVED WORKSFORME

Status

Tech Evangelism Graveyard
English US
RESOLVED WORKSFORME
16 years ago
3 years ago

People

(Reporter: Jeremy Manson, Unassigned)

Tracking

Details

(Whiteboard: evil UA detection for Linux Mozilla?, URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
BuildID:    2002061014

On this page, there are little buttons marked "search".  Next to these buttons,
in IE, there are a couple of pulldowns and a search box, labelled "Sponsored by
CitySearch".  On Mozilla, there is nothing but a lilac colored field.

I tried this on OS X and Linux, so I am extrapolating to "all".  It is also
broken on the browser from which I am submitting, an earlier revision.

This is probably a dup of some well known bug, or a tech evangelism bug, but I
don't know enough of the ins and outs of standard HTML to know what to search
for on bugzilla.  I searched for "washingtonpost.com", but couldn't find anything.

Reproducible: Always
Steps to Reproduce:
1. Launch browser
2. Navigate to above URL
Changing "document.object1.document.write(desc);"
to "document.getElementById('object1').innerHTML = desc;"
in one of the JavaScript files makes the search form appear.

-> Evangelism
Component: Layout → US General
Product: Browser → Tech Evangelism
Version: other → unspecified
Reassigning...
Assignee: attinasi → doron
QA Contact: petersen → zach
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Does not display search box properly → eg.washingtonpost.com - Does not display search box properly
*** Bug 156819 has been marked as a duplicate of this bug. ***

Comment 4

16 years ago
*** Bug 164059 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
-->bclary
Assignee: doron → bclary

Updated

16 years ago
Summary: eg.washingtonpost.com - Does not display search box properly → washingtonpost.com - Does not display search box properly
(Reporter)

Comment 6

16 years ago
I don't want to jump the gun, but this page seems to work in 1.2.1

Comment 7

16 years ago
I agree.  WFM using 1.2.1 on Win2K.

Comment 8

16 years ago
yep. looks fine. roll over the search displays the topic subsearch well. Thanks!
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 9

16 years ago
Doesn't work for me on Linux, both on a custom build (pulled from the tree 11/30
 after the version strings changed), and on a build I got from mozilla.org. 
Jeremy Manson, what OS are you using?

If someone on Linux doesn't have this working (i.e. embarrass me), should it be
reopened, or should I submit a new bug?

Comment 10

16 years ago
Rich,

If it is still borken on linux, please reopen but please try a fresh version of
mozilla and report the ua. 
(Reporter)

Comment 11

16 years ago
I tried 1.2.1 on Win32 and OS X.  Actually, I went back and tried 1.1 on Linux,
which, as you say, seems not to work  Perhaps they have some weird user-agent
detection badness.

Comment 12

16 years ago
Still doesn't work with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207
(The build ID for this is 2002120705)
and
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
(Couldn't find the Build ID for this one).

Someone more powerful than me needs to reopen this bug (Bugzilla wouldn't let me).
REOPENing as per comments nine through twelve.

WFM on Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021207
Chimera/0.6+ though.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: evil UA detection for Linux Mozilla?

Comment 14

16 years ago
I get this message in my JavaScript console when I try to visit that page:

Error: document.getElementById("coretool") has no properties
Source File:
http://www.washingtonpost.com/wp-srv/entertainment/javascript/front/coretool.js
Line: 53

Any of the WFM's get this?  I'm not up on JavaScript, so I'm not sure what it means.

Updated

16 years ago
Keywords: evang500

Comment 15

16 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

I find that if the lilac area remains blank, then the status bar shows:
"Transferring data from ad.doubleclick.net..."

Other times the page works correctly (though the lilac area runs over to the
right, with some improvement after the first mouseover).  In this case, the
status bar does not hang waiting for doubleclick.

So a test would be to mess up the doubleclick reference or proxy it out.  Or it
could be a cookie issue.

Note: popup blocking causes problems on some washingtonpost.com pages, such as
http://www.washingtonpost.com/wp-srv/liveonline/schedule.htm
I could not get any predictable result by toggling "Reject Popup Windows" for
the current bug's URL.  The pop-up blocking problem leads to a js error.

Error: poupwin has no properties
Source File: http://www.washingtonpost.com/wp-srv/liveonline/schedule.htm
Line: 15

Obvious.  Then clicking it to view source yields:

Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://cookie/content/cookieTasksOverlay.xul :: CookieTasksStartup :: line 84"
 data: no]

Comment 16

16 years ago
Might be Bug 53967, see comment #28.
http://bugzilla.mozilla.org/show_bug.cgi?id=53967#c28

Javascipt may be waiting for network data to render, or it's hung up on a cookie.

Comment 17

16 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

This is definitely a UA-sniffing problem.  I installed uabar, and set the UA
string from the above to NS 7 on WinXP, and the search boxes appeared.

With respect to comment 15 and comment 16, I've noticed random "Transferring
data from ad.doubleclick.net..." "hangs" on many washingtonpost.com articles,
almost always involving pages with Obnoxious Flash Ads.  My guess is that
behavior isn't directly related to this bug.

Comment 18

16 years ago
I saw the blank lilac field if and only if I had the "Transferring data from
ad.doubleclick.net..." status hanging.  I saw each case several times: both
succeed or both hang.  In addition, I don't think "doubleclick" is in the HTML
source; it's loaded from javascript.  That's why I suspect bad handling of a
network delay, or a cookie problem.  (I probably should not have posted all that
popup blocker stuff; I don't think that's related.)

Comment 19

15 years ago
tech evang june 2003 reorg
Assignee: bc → english-us
Status: REOPENED → NEW
QA Contact: zach → english-us

Comment 20

14 years ago
I think this bug can be closed, since I couldn't find anymore the mentioned
search boxes on the site

Comment 21

14 years ago
thanks pascal. wfm
Status: NEW → RESOLVED
Last Resolved: 16 years ago14 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.