Bug 125444 - [GTK] REGRESSION: www.yahoo.com redirects to the mobile version after UA change
Summary: [GTK] REGRESSION: www.yahoo.com redirects to the mobile version after UA change
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Gustavo Noronha (kov)
URL: http://www.yahoo.com
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-09 03:10 PST by Sergio Villar Senin
Modified: 2016-01-17 12:12 PST (History)
7 users (show)

See Also:

Attachments
Patch (3.02 KB, patch)
2013-12-09 10:11 PST, Gustavo Noronha (kov) 		mrobinson: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio Villar Senin 2013-12-09 03:10:24 PST 
The recent UA change from bug 124229 triggered this because if I revert to the old UA then I get the desktop version.
Comment 1 Alberto Garcia 2013-12-09 09:38:05 PST 
Related: bug 125432
Comment 2 Gustavo Noronha (kov) 2013-12-09 10:11:49 PST 
Created attachment 218773 [details]
Patch
Comment 3 Alberto Garcia 2013-12-09 10:22:23 PST 
I cannot reproduce this with Epiphany btw :?
Comment 4 Alberto Garcia 2013-12-09 10:28:29 PST 
Ah yeah, if I replace X11; Linux x86_64 with X11; Intel Mac OS X then
it redirects.
Comment 5 Víctor M. Jáquez L. 2013-12-09 10:32:46 PST 
(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.
Comment 6 Gustavo Noronha (kov) 2013-12-09 10:50:55 PST 
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?
Comment 7 Víctor M. Jáquez L. 2013-12-09 11:12:40 PST 
(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!
Comment 8 Gustavo Noronha (kov) 2013-12-09 11:18:09 PST 
(In reply to comment #7)
> oops! Sorry, I misread your patch. Now I got it. Thanks!

o/\o
Comment 9 Adrian Bunk 2013-12-09 20:00:26 PST 
(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.
Comment 10 Adrian Bunk 2013-12-09 21:04:13 PST 
(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 11 Sergio Villar Senin 2013-12-10 00:32:57 PST 
Comment on attachment 218773 [details]
Patch

I'm all for the patch
Comment 12 Gustavo Noronha (kov) 2013-12-10 02:17:43 PST 
Committed r160354: <http://trac.webkit.org/changeset/160354>
Comment 13 Michael Catanzaro 2016-01-17 12:12:25 PST 
This quirk seems to no longer be needed, at least in my testing. I remove it in a patch in bug #142074.