343367 - Mapquest maps fail to display, always, in SeaMonkey

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Kent Paul Dolan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060612 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060612 SeaMonkey/1.5a

Mapquest maps, such as the example URL for the city
of Kenmore, WA, display as blank spaces the correct
size for a map in SeaMonkey, display as expected in
Internet Explorer 6.0. I believe, but no longer
maintain a copy to test this, that the same failure
occurs in Firefox 1.5a as well.

This is _not_ bug 326030, my

  preferences => privacy & security => images

setting is to accept all images. 

The failure may be related to some generalized allergy
of SeaMonkey for GIFs, but I don't find evidence of that
in other bug reports.

xanthian.



Reproducible: Always

Steps to Reproduce:
1. Open above URL.
2. Notice hole where map should be.
3.

Actual Results:  
All of the page renders correctly except the map,
which instead is left as an empty space the proper
size for the map. The space really is empty,
not merely the map rendered all in white;
right clicking on the empty space doesn't
bring up a "view image" on the popup menu.


Expected Results:  
Normal rendering of the web page as seen under I.E. 6.0.


Bug 342975 describes the SeaMonkey setup on this
laptop. I haven't tested this failure with a
clean profile, but since the failure is shared
(IIRC) with Firefox, that's probably not a useful
test to run anyway, unless some maintainer finds
a WFM on this URL.

Comment 1

[Mats Palmgren (inactive)]

WFM, 2006-06-30-01 SeaMonkey trunk Linux.

Kent, does the problem occur if you start Firefox in Safe Mode?
http://kb.mozillazine.org/Safe_mode

Comment 2

[Kent Paul Dolan]

(In reply to comment #1)
> WFM, 2006-06-30-01 SeaMonkey trunk Linux.

Still fails for me, with the aforementioned SeaMonkey nightly build,
2006061209, even when (in a second try) run with a clean profile.

> Kent, does the problem occur if you start Firefox in Safe Mode?
> http://kb.mozillazine.org/Safe_mode

I downloaded today's FireFox "MineField" nightly build, brought it up
in Safe Mode, clicked all four "reset to nominal" boxes, relaunched
Safe Mode, and the identical failure occurs.

I'm posting this from SeaMonkey. The version of Minefield I used for testing identifies itself as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060705 Minefield/3.0a1"

What next? I'm running the MS-WinXP "Media Center" or some such hype-named
OS release, which may or may not be WinXP Professional; it came in my new
computer, in any case, and is kept up to date with the current Microsoft 
patches.

xanthian.

Comment 3

[Mats Palmgren (inactive)]

Ok, I can now reproduce it in recent SeaMonkey and Firefox builds. I must
have used a lightly tainted profile the first time around, sorry.

Comment 4

[Mats Palmgren (inactive)]

The regression range is 2006-03-07-04  --  2006-03-07-14:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-07+02%3A00&maxdate=2006-03-07+16%3A00&cvsroot=%2Fcvsroot

It looks like this bug could be related to bug 335251 - same doamin and
same regression range.

FWIW, I noticed that if I "block all cookies" then the site seems to work,
at least I can click on the image to zoom in, for example.

Comment 5

[Kent Paul Dolan]

I got email saying that this bug was "FIXED",
because the bug it depends upon changed state.

Yet, I don't find it marked "fixed" when I
come here, and the failing behavior is still
in at least the 2006071108 MS-Windows nightly
build, which I installed yeterday and tested
today.

What's up?

xanthian.

Comment 6

[Alex Vincent [:WeirdAl]]

What you got was the message that the dependent bug was fixed, not this one.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #5)
> and the failing behavior is still
> in at least the 2006071108 MS-Windows nightly
> build,


2006071109 certainly doesn't have the fix.
Bug 335251 was fixed @2006-07-12 10:59

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Reporter, do you still see this bug?

Comment 9

[Kent Paul Dolan]

(In reply to comment #8)
> Reporter, do you still see this bug?

No, and in fact I used MapQuest with the
2006080108 SeaMonkey 1.5a build just today,
without even considering that it hadn't
worked earlier.

xanthian.