Summary: | [GTK] REGRESSION: www.yahoo.com redirects to the mobile version after UA change | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Sergio Villar Senin <svillar> | ||||
Component: | WebKitGTK | Assignee: | Gustavo Noronha (kov) <gustavo> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | berto, bunk, gustavo, mcatanzaro, mrobinson, rishi.is, vjaquez | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
URL: | http://www.yahoo.com | ||||||
Attachments: |
|
Description
Sergio Villar Senin
2013-12-09 03:10:24 PST
Related: bug 125432 Created attachment 218773 [details]
Patch
I cannot reproduce this with Epiphany btw :? Ah yeah, if I replace X11; Linux x86_64 with X11; Intel Mac OS X then it redirects. (In reply to comment #2) > Created an attachment (id=218773) [details] > Patch This patch is very similar with my first one https://bug-124229-attachments.webkit.org/attachment.cgi?id=216802 But @mrobinson commented this https://bugs.webkit.org/show_bug.cgi?id=124229#c8 So I think we're in a kind of a dilemma: some site will redirect us if change it; some other will do too if we doesn't. I don't get your point Victor, what this patch does is claim to be Mac OS X properly (by not keeping the X11), it doesn't contradict Martin's comment you linked to. Do you know of a site that breaks with this patch? (In reply to comment #6) > I don't get your point Victor, what this patch does is claim to be Mac OS X properly (by not keeping the X11), it doesn't contradict Martin's comment you linked to. Do you know of a site that breaks with this patch? oops! Sorry, I misread your patch. Now I got it. Thanks! (In reply to comment #7) > oops! Sorry, I misread your patch. Now I got it. Thanks! o/\o (In reply to comment #2) > Created an attachment (id=218773) [details] > Patch I'm curious how the Windows build managed to succeed - just by looking at the patch I would have expected it to fail on an undefined cpuDescriptionForUAString() since the #if guard for that version is not removed. (In reply to comment #9) > (In reply to comment #2) > > Created an attachment (id=218773) [details] [details] > > Patch > > I'm curious how the Windows build managed to succeed - just by looking at the patch I would have expected it to fail on an undefined cpuDescriptionForUAString() since the #if guard for that version is not removed. Oh right, the Windows build is not a WebKitGTK+ build. Comment on attachment 218773 [details]
Patch
I'm all for the patch
Committed r160354: <http://trac.webkit.org/changeset/160354> This quirk seems to no longer be needed, at least in my testing. I remove it in a patch in bug #142074. |