Mapquest maps fail to display, always, in SeaMonkey

RESOLVED WORKSFORME

Status

()

Core
DOM: Events
--
major
RESOLVED WORKSFORME
12 years ago
12 years ago

People

(Reporter: Kent Paul Dolan, Unassigned)

Tracking

({regression, top100})

Trunk
x86
All
regression, top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

12 years ago
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
(Reporter)

Comment 2

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

12 years ago
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.
Status: UNCONFIRMED → NEW
Component: General → General
Ever confirmed: true
Keywords: top100
OS: Windows XP → All
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk

Comment 4

12 years ago
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.
Assignee: general → events
Component: General → DOM: Events
Depends on: 335251
Keywords: regression
QA Contact: general → ian
(Reporter)

Comment 5

12 years ago
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.
What you got was the message that the dependent bug was fixed, not this one.

Comment 7

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

12 years ago
Reporter, do you still see this bug?
(Reporter)

Comment 9

12 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.