Closed Bug 780393 Opened 7 years ago Closed 7 years ago

portauthority.org/paac displays poorly without Gecko/20100101

Categories

(Tech Evangelism Graveyard :: English US, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: walts48, Unassigned)

References

()

Details

(Whiteboard: [fixed by backout, bug 815743])

Attachments

(1 file)

I noticed this problem when Aurora 16.0a2 was Nightly 16.0a1. Now both Aurora and Nightly do not render this page properly.

Site works with:

Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0

Doesn't work with:

Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0
Contacted the Port Authority, and they responded with,

"Thank you for contacting the Port Authority. Your information has been forwarded to the appropriate department."
Site now works with Aurora because the UA is Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20120818 Firefox/16.0
Site broken again in Aurora, with today's update to:

Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0

Build ID:20120828042007
OK. I decided to close this as WFM because it appears each release changes Gecko/Version back to Gecko/20100101 and the site then works. 

Confusing, but as long as it works in releases users (me) will be happy.

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Note that bug 588909 remains active in the aurora channel (currently 17.0), at least for now, and has been on trunk. It has only been backed out for previous versions in the aurora channel due to problems with various sites.

Your case appears similar, thus I'd suggest reopening this bug assuming that, with Gecko 17.0, the UA-string change may become permanent also for releases.
Reopening because the UA string in Firefox 17.0 now reads Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0, and the site no longer displays properly.

Still displays properly in Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Confirming, and it also works the other way (i.e., replacing Gecko/<date> by Gecko/<version> in a current release causes the same display issues, thus definitely related to UA string and not some other difference between Gecko versions).

I assume that this is supposed to block the originating bug as a regression, thus setting the respective dependencies.
Blocks: 588909
Status: UNCONFIRMED → NEW
Ever confirmed: true
On Firefox for Android Beta, the desktop page prompts for a download instead of displaying anything at all.
Status: NEW → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [fixed by backout, bug 815743]
Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 SeaMonkey/2.14.1

This is still a valid Tech Evangelism bug.  The problem involves improper UA sniffing.  With the UA string above (SeaMonkey's "Advertise Firefox compatibility" disabled), the cited Web page has links and graphics overlaying each other, making a hard-to-read mess.  I see this with SeaMonkey 2.14.1, which includes the fix for bug #815743.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Yes and no - this bug was opened for the Gecko/<date> missing in the UA string and thus causing the site to fail, the lack of the Firefox compatibility portion is independent from bug 588909 and a hence separate issue. Please open/clone a new bug for the compatibility token, otherwise it's getting confusing.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 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.