486572 - yellowpages.ca -- fails to draw pushpins if "Firefox" is not present in UA string

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English Other, defect)

Description

[Asher]

User-Agent:       Mozilla/4.8 [en] (Windows NT 6.0; U)
Build Identifier: 

When you do a query for a place on yellowpages.ca, a pushpin image demonstrates where on the map it is. For example: http://www.yellowpages.ca/bus/Ontario/North-York/Sharma-Naresh-Dr/2532405.html?what=dentist&where=toronto&le=6088175ff2|6088171186|60881711eb|6088171250|60881712b5

In FF 3.5 nightlies, the pushpin does not draw.  This is a regression: it does work in FF 3 (and 2 as well), it works in IE 6, 7, 8, Safari 3 & 4, Opera 9 & 10, and Chrome 1 & 2 as well.  FF 3.5 is the only major browser which fails to render it.

Reproducible: Always

Steps to Reproduce:
1. Visit yellowpages.ca
2. Search for a listing
3. View a listing

Actual Results:  
There is no pushpin with FF3.5 branch builds

Expected Results:  
Pushpin should display where on map business is located

Comment 1

[Asher]

Attachment: Testcase reduction

This is my attempt at a testcase reduction.  It still links to rather large JS libs though.

As a sidenote: I've also disabled TM (set the JIT about:config to false for both), and it makes no difference.

Comment 2

[Nickolay_Ponomarev]

Thanks for the report. I can reproduce on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090403 Shiretoko/3.5b4pre, but it's hard to know if this is a known issue (or what the issue might be caused by) without more information, since the testcase is rather complex.

Could you
1) test in a trunk nightly to see if it's also an issue there: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ? (It might be a known issue that's fixed on trunk)
2) Help finding the regression window to figure out what change (on trunk) caused the regression:
http://quality.mozilla.org/projects/finding-regression-windows
?

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

(In reply to comment #1)
> Created an attachment (id=370712) [details]
> Testcase reduction

this is WFM using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090403 ID:20090403050211
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090403 ID:20090403044228

Comment 4

[Asher]

Really? Do you see the yellow pushpin (not the annoying Birds Eye callout that draws).

I've tested this using today's nightly branch on OS X and Windows and it still doesn't draw.

I'll see if I have time to reduce this testcase further.

Comment 5

[Ria Klaassen (not reading all bugmail)]

This is probably a case of wrong browser detection. It seems to sniff for the word Firefox in the useragent string.
I gave the pref general.useragent.extra.firefox the value Firefox/3.0.8 and then suddenly the yellow pin appeared. Without that I see the error:

Error: uncaught exception: Msn.Drawing.Exception: Your Web browser does not support SVG or VML. Some graphics features may not function properly.

Comment 6

[Chris Lawson (gone)]

Yeah, this is definitely broken sniffing. Works fine in Camino trunk, pushpin disappears if you remove the "like Firefox" portion of the UA.

Comment 7

[Asher]

Thanks guys.  I know the yellowpages guys so I'll ensure this is fixed.

Comment 8

[Chris Lawson (gone)]

Assigning to the reporter per comment 7.

Comment 9

[Chris Lawson (gone)]

Dave, you'll probably find

http://www.geckoisgecko.info/

to be useful when explaining to them that they should be sniffing for features first, *then* rendering engine. (There's rarely any reason at all to sniff for a specific browser version, since all browsers based on a given rendering engine version are, in theory, rendering content the same way.) It's just as easy to sniff for "Gecko" as it is for "Firefox", and as an added bonus, you don't have to worry about doing extra work to support Firefox nightlies (which don't have "Firefox" in the UA string) or other Gecko browsers like Camino.

cl

Comment 10

[Asher]

Worked with yellowpages.ca.  They were responsive and got this fixed in time for the next release which should go out "shortly".  I played with it on their test site and confirmed it's fixed (they now test for Gecko, not FF).

Thanks for everyone's help.