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

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

Product:	WebKit
Classification:	Unclassified
Component:	WebKit Gtk
Version:	528+ (Nightly build)
Platform:	Unspecified Unspecified

Importance:	P2 Normal
Assigned To:	Gustavo Noronha (kov)

URL:	http://www.yahoo.com
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2013-12-09 03:10 PST by Sergio Villar Senin
Modified:	2013-12-10 06:03 PST (History)
CC List:	6 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>