Closed
Bug 103639
Opened 23 years ago
Closed 21 years ago
washingtonpost.com - New "my" washingtonpost.com website fails to render in mozilla
Categories
(Tech Evangelism Graveyard :: English US, defect, P2)
Tech Evangelism Graveyard
English US
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: corey, Assigned: doronr)
References
()
Details
Attachments
(3 files)
1. load browser 2. go to URL: http://my.washingtonpost.com/ * Expected Result: Page should render in a readable manner * Current Result: Upon first load, user briefly sees correct page layout. Shortly thereafter, however, everything disappears except for a banner ad on the lefthand side, and a misplaced stock quotes table. Throbber continues to move, as if it is still trying to load a portion of the page; This continues indefinitely. I am attaching a screenshot of the Current Result. Included is the washingtonpost pop-up that has a miniature picture of what my.washingtonpost.com should look like. I haven't had the time to get this from MSIE, and it crashes NS 4.x on my linux box :P.
Comment 2•23 years ago
|
||
Same thing happens in 2001100708 on NT4. But I wouldn't be surprised if it was the site being rubbish.
Assignee | ||
Comment 3•23 years ago
|
||
-> te, confirming
Assignee: asa → bclary
Status: UNCONFIRMED → NEW
Component: Browser-General → English: US
Ever confirmed: true
OS: Linux → All
Product: Browser → Tech Evangelism
QA Contact: doronr → zach
Hardware: Other → All
Version: other → unspecified
Comment 4•23 years ago
|
||
If it's really "my washington post" I should be able to fix it... guessing p2
Priority: -- → P2
Summary: New "my" washingtonpost.com website fails to render in mozilla → my.washingtonpost.com - New "my" washingtonpost.com website fails to render in mozilla
Updated•23 years ago
|
Summary: my.washingtonpost.com - New "my" washingtonpost.com website fails to render in mozilla → washingtonpost.com - New "my" washingtonpost.com website fails to render in mozilla
Updated•23 years ago
|
Whiteboard: aok
Comment 5•23 years ago
|
||
Mass reassign of all tech-evangelism us general bugs assigned to bc to doron except bc's P1 bugs. You may search for this mass reassign (it is 305 bugs) by searching for the keyword 'greeneggsandham'
Assignee: bclary → doronr
Comment 6•23 years ago
|
||
*** Bug 127548 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 8•22 years ago
|
||
still seein, but older build
Still seeing, in new build. (2002041721 linux) in old build, looked same, but protocol was that "wcisywg" or whatever instead of http
Comment 10•22 years ago
|
||
I use Mozilla on 3 PCs. I had this exact problem on one of them. The other two worked fine from the beginning. In the one with the problem (Win2K SP3 and Mozilla 1.1 as well as various nightlies) I deleted all the washingtonpost.com related cookies, signed in again, and it worked fine. If you're still having the problem, reocommend that you delete all the related cookies and try again.
Comment 11•22 years ago
|
||
I spoke to soon. I'm having trouble again on the difficult machine and simply deleting the cookies isn't enough to do the job. I found that if you go in through the main page --> style --> comics (at which point you will be forced to log in) and then click on the MyWashingtonPost.com icon it will sometimes work. I'll see if I can figure anything else out and report back.
Comment 12•22 years ago
|
||
It seems that the problem is in the sign in page that the normal entry through the MyWashingtonPost.com link (upper right of main page). If I log in (and stay logged in) through the comics page as I mentioned yesterday, it seems to work when I go to MyWashingtonPost.com.
Comment 13•22 years ago
|
||
I am officially confused. Here is what I've been able to figure out: When you go to the MyWashingtonPost.com feature you go to: http://www.washingtonpost.com/ac2/wp-dyn?node=personalization/mywp/display&destination=startPage&nextstep=refresh This page will send you to: http://www.washingtonpost.com/wp-dyn/personalization/mywp/display You get there in this tag: <SPAN name="staticSpan" id="staticSpan" style="position: absolute; top:2; left:2; include-source:url(http://www.washingtonpost.com/wp-dyn/personalization/mywp/display);"></SPAN> If you simply paste that url into the navigation toolbar, it works perfectly. Somehow the fact that it is getting called from within this tag seems to be causing a problem. I'm attaching to the two html files in total. I don't know enough about javascript to reduce this to a test case. At the very least, the work around is to go to directly to http://www.washingtonpost.com/wp-dyn/personalization/mywp/display) to log in.
Comment 14•22 years ago
|
||
Comment 15•22 years ago
|
||
See also Bug 177564. I will leave this open however. I have contacted the site with some suggested work arounds.
Comment 16•22 years ago
|
||
I just wanted to point out that this problem does not occur with IE 5.2.1 or Safari running under MacOS 10.2.3.
Comment 17•21 years ago
|
||
It would appear that something on the site has changed. WFM now using both 1.3a and 1.3b. Unless someone else is still seeing this, recommend close.
Reporter | ||
Comment 18•21 years ago
|
||
Confirming -- now works for me (originator), too. Changing resolution to 'WORKSFORME'
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Updated•9 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
Comment 19•9 years ago
|
||
http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ Photo obscures text underneath
You need to log in
before you can comment on or make changes to this bug.
Description
•