[GTK] REGRESSION: www.yahoo.com redirects to the mobile version after UA change

[Sergio Villar Senin]

The recent UA change from bug 124229 triggered this because if I revert to the old UA then I get the desktop version.

[Alberto Garcia]

Related: bug 125432

[Gustavo Noronha (kov)]

Created attachment 218773 [details]
Patch

[Alberto Garcia]

I cannot reproduce this with Epiphany btw :?

[Alberto Garcia]

Ah yeah, if I replace X11; Linux x86_64 with X11; Intel Mac OS X then
it redirects.

[Víctor M. Jáquez L.]

(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.

[Gustavo Noronha (kov)]

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?

[Víctor M. Jáquez L.]

(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!

[Gustavo Noronha (kov)]

(In reply to comment #7)
> oops! Sorry, I misread your patch. Now I got it. Thanks!

o/\o

[Adrian Bunk]

(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.

[Adrian Bunk]

(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.

[Sergio Villar Senin]

Comment on attachment 218773 [details]
Patch

I'm all for the patch

[Gustavo Noronha (kov)]

Committed r160354: <http://trac.webkit.org/changeset/160354>

[Michael Catanzaro]

This quirk seems to no longer be needed, at least in my testing. I remove it in a patch in bug #142074.