How can I help make this happen now that https://bugs.webkit.org/show_bug.cgi?id=17375 is fixed?

Would you think having a file in /usr/share/epiphany for this is a good thing? A gconf key?

I think a gconf key sounds better, but I guess it's also a good idea to keep backwards compatibility when possible. Since you are a distributor, what's your opinion? Is a gconf key more convenient or would you rather stick with the old solution?

Also, no matter what we do, this should be possible to override from an extension, which I'm pretty sure someone will write sooner or later.

(In reply to comment #2)
> I think a gconf key sounds better, but I guess it's also a good idea to keep
> backwards compatibility when possible. Since you are a distributor, what's your
> opinion? Is a gconf key more convenient or would you rather stick with the old
> solution?

(backwards compatibility here is possible if you want to ship the same file that was shipped with ephy-gecko, in some chrome directory)

For openSUSE, both methods are fine. I would think that it's easier for distros to change a default gconf value, though.

Thinking a bit more about this: vendors don't want a key to set the whole user agent, they just want to append "openSUSE/blablabla" or "Debian/blablabla" to the user agent, where blablabla would likely be the package version.

So if we want to use a gconf key, it'd be user_agent_os_vendor, I think.

Created attachment 139827 [details] [review]
Patch

Okay, this is a patch I might use for openSUSE. Comments welcome.

(it certainly doesn't handle the extension stuff you wanted)

Fred, do you have an opinion on this?

Created attachment 140109 [details] [review]
Second approach

This second approach might actually make more sense, after thinking about it. It does this:

 + look at /apps/epiphany/general/user_agent. Use the value of this key if it's non-empty. (it's empty by default)

 + else, use the webkit UA + Epiphany/VERSION. And optionally append a vendor value that is taken from /usr/share/epiphany/branding.conf. If the file doesn't exist, then there's no vendor added.

This file would look like this:
[User Agent]
Vendor=SUSE/2.27.90

The reason it might be better this way is that it really doesn't make sense to have some gconf key for vendor information, since it's not a preference.

Comment welcome, etc.

Note that this adds new strings (gconf schema) so it'd be nice to have a solution before the string freeze :-)

Created attachment 140128 [details] [review]
Updated patch for second approach

After talking with Alexander Sack, it seems doing it this way is better.

branding.conf would now contain:

[User Agent]
Vendor=SUSE
VendorSub=11.2
VendorComment=2.27.90-1

And the result would be:

Mozilla/5.0 (X11; U; Linux i686; fr-fr) AppleWebKit/531.2+ (KHTML, like Gecko) Safari/531.2+ SUSE/11.2 (2.27.90-1) Epiphany/2.27.90

(apparently, it's better to put the vendor before the browser; that's what firefox does)

(In reply to comment #8)
> And the result would be:
> 
> Mozilla/5.0 (X11; U; Linux i686; fr-fr) AppleWebKit/531.2+ (KHTML, like Gecko)
> Safari/531.2+ SUSE/11.2 (2.27.90-1) Epiphany/2.27.90
> 
> (apparently, it's better to put the vendor before the browser; that's what
> firefox does)

The spec says: "By convention, the products are listed in order of their significance for identifying the application." The fact that it's "Epiphany 2.27.90" tells you more about the application than the fact that it's part of SUSE 11.2, so Epiphany should come first.

Well, I'd agree. It's just that Firefox doesn't do it this way, and some broken parsers on servers might rely on this...

Anyway, it's just two lines to change, so quite easy.

I can imagine the news in slashdot... "google's secret operating system is codenamed EPIPHANY and uses webkit"

(In reply to comment #10)
> Well, I'd agree. It's just that Firefox doesn't do it this way, and some broken
> parsers on servers might rely on this...

If there is someone out there with a server that relies on "Epiphany" being the last token in a User-Agent string, we can just find them on irc.gnome.org and ask them to fix it. :-)

People who parse User-Agent are doing it to see whether you are Firefox or Internet Explorer. It doesn't matter how they parse *our* User-Agent string, because they're going to do something stupid and incorrect with it regardless.

Also, I am thinking now that

    Epiphany/2.27.0 (SUSE 11.2, 2.27.0-1)

would be more correct. But whatever.

(In reply to comment #9)
> The spec says: "By convention, the products are listed in order of their
> significance for identifying the application." The fact that it's "Epiphany
> 2.27.90" tells you more about the application than the fact that it's part of
> SUSE 11.2, so Epiphany should come first.
> 

What spec are you reading? This one: https://developer.mozilla.org/en/User_Agent_Strings_Reference seems to be the latest and it does not say that.

I agree with the general sentiment that putting Epiphany first makes more sense for identification purposes, although as you also mention, it's unlikely that this will matter at all...

(In reply to comment #13)
> What spec are you reading? This one:
> https://developer.mozilla.org/en/User_Agent_Strings_Reference seems to be the
> latest and it does not say that.

I was talking about the HTTP/1.1 spec, RFC 2616. Apparently at least the first version of the Mozilla spec pre-dates that, since it refers to obeying "the standard described in RFC 1945 and RFC 2068" :)

Anyway, this spec also seems to say that browsers that are based on Gecko but not on the mozilla source tree should not use "Mozilla/...", so it's clearly not designed to reflect the realities of User-Agent sniffing.

Although, FWIW, apparently Opera doesn't include a Mozilla/ piece any more.

We need to do *something* here; right now we're not even including "Epiphany" in the User-Agent...

I don't know if this is the right place for this comment, but it would be good if it was possible (by way of an extension) to override the user agent.

There's sadly still a need for this.

I have pushed this to master with very small style modifications, thank you!