Closed Bug 1242294 Opened 9 years ago Closed 5 years ago

Update how Firefox compatibility is advertised

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(seamonkey2.49esr wontfix, seamonkey2.53+ fixed, seamonkey2.57esr? affected)

Status:
RESOLVED FIXED
Milestone:
seamonkey 2.74
Tracking Flags:
Tracking Status
seamonkey2.49esr --- wontfix
seamonkey2.53 + fixed
seamonkey2.57esr ? affected

People

(Reporter: buc, Assigned: iannbugzilla)

References

(Blocks 1 open bug)

Details

(Whiteboard: SM2.53.3)

Attachments

(3 files, 11 obsolete files)

Firefox strict mozilla patch v1.1
(deleted), patch
frg
: review+
buc
: feedback+
frg
: approval-comm-release+
frg
: approval-comm-esr60+
Details | Diff | Splinter Review
Firefox strict comm patch v1.2
(deleted), patch
iannbugzilla
: review+
iannbugzilla
: approval-comm-release+
iannbugzilla
: approval-comm-esr60+
Details | Diff | Splinter Review
Help patch v1.3
(deleted), patch
iannbugzilla
: review+
iannbugzilla
: approval-comm-release+
iannbugzilla
: approval-comm-esr60+
Details | Diff | Splinter Review
Some sites, especially banks, are too pedantic. Such sites often drop clients with "unknown", "not usual", "malformed" user-agent strings. The "general.useragent.compatMode.filerox" adds "Forefox/N.N" to UA, and it helped before. Now, the sites become yet more strictly and yet no more politcorrect to not "usual 5 browsers in the World" :(. IOW, the presence of "SeaMonkey/N.N" in the useragent string prevents some sites to work *even* when "Firefox" is mentioned. Now user have to manually set "general.useragent.override" (ie. goto "about:", copy the useragent string without last SeaMonkey part, then goto "about:config" etc. and set new useragent). It is inconvenient. The better way is to either provide an option to switch SeaMonkey in UA off, or just drop it from UA when Firefox compat mode is on. The proposed patch for last case ia attached.
My opinion: I see that as a problem of those sites, not of SeaMonkey. A Bank which only wants to have mainstream average humans as customers with a mainstream browser THEY know deserves to loose customers. For those few parochial banks which have a compelling offer "general.useragent.compatMode.filerox" (or may be an add-on) should be enough. I doubt that it helps that we add lots of (possibly bad documented) of adaptation features nobody will find when he deeds them.
Severity: normal → enhancement
(In reply to Rainer Bielefeld from comment #1) May be we first should have a collection "frequently changed about:config parameters" (in the wiki?), and when we have some overview we can decide shether, where and how we will ease changing those preferences.
> I see that as a problem of those sites, not of SeaMonkey In theory, yes. But real life is more complicated. :( As a precedent: consider why there is "Gecko/20100101" substring in the useragent now, whereas the actual Gecko has another version.
(In reply to Dmitry Butskoy from comment #3) > > I see that as a problem of those sites, not of SeaMonkey > > In theory, yes. But real life is more complicated. :( > > As a precedent: consider why there is "Gecko/20100101" substring in the > useragent now, whereas the actual Gecko has another version. That was because some paranoid users thought that having a too specific Gecko version string would allow them to be "personally traced" by (let's be polite) "commercial" sites. I remember following the whole discussion a few years ago. The UI locale was dropped from the UA string at approximately the same time. If we were "fully" masquerading as "true" Firefox and not as "SeaMonkey, Firefox's born-again grandmother", then even sites which know the difference (and know that both can be trusted) wouldn't be able to tell us apart and they would attribute SeaMonkey's whole market slice to Firefox. IIRC, one place where it would hurt is in Google searches, where every search accomplished with a Mozilla browser contributes to Google's subsidies to Mozilla. These subsidies are allocated against user-agent strings, and (IIUC) MoFo retrocedes to the SeaMonkey Council the part that comes from SeaMonkey user-agents. There might also be (but IANAL, and I'm not sure) trademark issues against _exactly_ mimicking Firefox. @IanN: I suggest WONTFIX. What do you think?
Component: General → Preferences
Flags: needinfo?(iann_bugzilla)
You mean SeaMonkey and Firefox are *different* browsers? Just exploring the source ("mozilla/" subdir), it is difficult to say that this is the case... The problem is not the "masquerading users", the problem is "the bank site denies me because I use strange browser, I was compelled to switch to FF and decided to be with it further". IOW SeaMonkey become the "not for end users" browser.
Probably it could be fine to allow regexp-like substitutions in UA string not for pre-sites basis only, but for general too. This way specifying: general.useragent.override = "(.) *SeaMonkey.*$#$1" will provide the same effect -- UA without SM menton, and no need to re-edit UA in about:config on each version change. Now such a regexping is allowed for per-sites (ie. general.useragent.override.*) only.
(In reply to Dmitry Butskoy from comment #5) > You mean SeaMonkey and Firefox are *different* browsers? > Just exploring the source ("mozilla/" subdir), it is difficult to say that > this is the case... The Mozilla subdirectory is a clone of the repository used for Firefox. The mere fact that it is a subdirectory and not the top directory is enough to me. One difference is what they call electrolysis: Firefox uses separate processes not only (as SeaMonkey does) for plugins but also for browser tabs. The tabbed browsers are so different that AFAIK there is not one tab-browsing extension which will run in both. (For example: not only the Tab Mix Plus author but also the specialist of adapting Firefox extensions to run in seaMonkey have both looked at the Tab Mix Plus extension and decided that it is not possible to adapt it for SeaMonkey.) The browser chrome is _extremely_ different, and so is the Preferences UI. And then of course, SeaMonkey is not just a browser, it's a Suite, which includes Mail&News, IRC Chat, and even a (more or less well working) HTML composer. > > The problem is not the "masquerading users", the problem is "the bank site > denies me because I use strange browser, I was compelled to switch to FF and > decided to be with it further". IOW SeaMonkey become the "not for end users" > browser. The problem, as you say, is with the bank site. Maybe they should be shown the http://geckoisgecko.org/ site: all those browsers are built on exaxtly the same HTML rendering engine and (at corresponding Gecko versions) they should interpret the same HTML+CSS+JS code the same way — unless, of course, the webpage code itself goes out of its way to ostracize this or that browser.
> the webpage code itself goes out of its way to ostracize this or that browser. It is exactly the case :( A user of some rare browser is not able to influence the IT-department of a big corporate bank or another such a site. Personally, the maximum that I can achieve is the understanding of ordinary employees and their regret that they can not change the company's technical policy. And "the policy" spits on a handful of users of the strange Firefox-like browser and never changes anything in the code for them. And "a handful of users" is the handful because people does not use SeaMonkey widely due to these problems etc. I agree that Firefox-masquerading must not be by default, but maybe give users a chance to reach a "big and bad" site when it is needed for their private life (besides the open source coding/using)?
@reporter: As already told there will be no (quick) SM code change for this particular need. A much more promising approach is a) to check whether an add-on does exist b) to create (or modify) an add-on for your needs I think you need a an extension which - creates general.useragent.override - adds a toolbar button what toggles between Default SeaMonkey User Agent String and a modified one for your needs. “Toolbar Buttons 1.1“ seems not to contain something useful for you. But may be “Custom Buttons” can be used as an example for a part of the needs? Or you can modify it for your needs? Or you find someone who I does the job for you? Or you find something you need at the “Custom buttons Projekct” <http://custombuttons.mozdev.org/>? Or we can do a SeaMonkey workshop “How to modify add-ons for your needs” and the example will be an addon for your needs - Tony, can you do or do you know someone who might be willing? As a very first step you should present how users can outfox such carping websites manually with "about:config" → "general.useragent.override" at <https://wiki.mozilla.org/SeaMonkey/FAQ#Troubleshooting>; please complete my stub.
(In reply to Rainer Bielefeld from comment #9) > @reporter: > As already told there will be no (quick) SM code change for this particular > need. > A much more promising approach is > a) to check whether an add-on does exist > b) to create (or modify) an add-on for your needs > > I think you need a an extension which > - creates general.useragent.override > - adds a toolbar button what toggles between Default SeaMonkey > User Agent String and a modified one for your needs. > > “Toolbar Buttons 1.1“ seems not to contain something useful for you. > But may be “Custom Buttons” can be used as an example for a part of the > needs? > Or you can modify it for your needs? Or you find someone who I does the job > for you? > Or you find something you need at the “Custom buttons Projekct” > <http://custombuttons.mozdev.org/>? > Or we can do a SeaMonkey workshop “How to modify add-ons for your needs” and > the example will be an addon for your needs - Tony, can you do or do you > know someone who might be willing? > > As a very first step you should present how users can outfox such carping > websites manually with "about:config" → "general.useragent.override" at > <https://wiki.mozilla.org/SeaMonkey/FAQ#Troubleshooting>; please complete my > stub. User Agent Switcher https://addons.mozilla.org/addon/user-agent-switcher/ allows you to customize the "fake" useragents you want to use (any number of them), and includes a toolbar button to switch between them and the "Default User Agent" which is the UA you'd have got if you hadn't been changing it. It assumes that the underlying application (SeaMonkey etc.) supports the preferences general.useragent.override
(In reply to Tony Mechelynck [:tonymec] from comment #10) Good shot! I mentioned this workaround in the trouble shooting guide (draft) <https://wiki.mozilla.org/SeaMonkey/FAQ#Troubleshooting> @reporter: Satisfying solution for you (considering ma and Tony's arguments)?
@reporter already knows (for years) what to do himself.:) Including addons, about:config etc. @reporter just tried to help "end user people", who find it difficult to deal with addons and any kind of hacking, and who want "all things work out of the box". Such a people download SM, start to use it, then they go to "the bad bank site", which denies them, then they switch to FF, and stay on FF, since SM does not work with "all the sites"...

Ping.

Probably a time to reconsider things, according to the current situation and practice with SM...

Flags: needinfo?(frgrahl)

Probably a time to reconsider things, according to the current situation and practice with SM...

No! I rather die on my feet than on my knees :)

Flags: needinfo?(frgrahl)

In the spirit of "soft power ", I allow myself to draw attention to a precedent of "FF-56 --> FF-60" mimicry.
The reason for such a mimicry is well-known.

I do not want to hurt the feelings of the developers ;), but the next step in this trend is obvious.

Consider the google.com -- it does not complain and works in general with SM mentioning in 2.53 (at least in Linux), but the search input field is broken a bit (two raws instead of one). Either google.com itself or some its scripts interprete SM in UA as "something but not the FF" and then behaves incorrectly.

We can collect more and more "bad" (from the Truth and our point of view) sites and specify them in default prefs, whereas when I removed SM mention (for my own use case) several years ago, I no longer have any problems at all...

Rhetorical question: How many sites will work better for our users if we leave SM in UA?

I do not want to hurt the feelings of the developers ;), but the next step in this trend is obvious.

There is no trend just fact. I think we all know it.

We don't want to get rid of it as default. If you provide a patch agains 2.53+ which does it via a pref like in the "Advertise Firefox Compatibility" this should be ok. Could be a third checkbox "Advertise SeaMonkey".

Rhetorical question: How many sites will work better for our users if we leave SM in UA?

Without the ua at least about:addons will probably have problems.

Flags: needinfo?(iann_bugzilla)

(In reply to Frank-Rainer Grahl (:frg) from comment #16)

We don't want to get rid of it as default. If you provide a patch agains 2.53+ which does it via a pref like in the "Advertise Firefox Compatibility" this should be ok. Could be a third checkbox "Advertise SeaMonkey".

Whether an extension can add its own advertising into UA string? (I saw somewhere something like " SeaMonkey/... Lightning/..." at the end of the string). If yes, then it must be deleted as well...

Rhetorical question: How many sites will work better for our users if we leave SM in UA?

Without the ua at least about:addons will probably have problems.

It seems that https://addons.thunderbird.net correctly point us to SM-related page even when SM is not mention in UA...

Flags: needinfo?(frgrahl)

It seems that https://addons.thunderbird.net correctly point us to SM-related page even when SM is not mention in UA...

I mean when we go there from about:addons ...

I think the checkbox should be "Look exactly as Firefox" (which describes its function more precisely).

Whether this phrase should be localized, and how to do this -- provide a patch against l10n tree?

(In reply to Dmitry Butskoy from comment #17)

Whether an extension can add its own advertising into UA string? (I saw somewhere something like " SeaMonkey/... Lightning/..." at the end of the string). If yes, then it must be deleted as well...

Well, I see Lightning uses "calendar.useragent.extra".
Is it likely that some other extensions add itselves to UA as well (ie. not UA-switching, but advertising of addons)?

Flags: needinfo?(frgrahl) → needinfo?(frgformenton)

typo in NI

Flags: needinfo?(frgformenton) → needinfo?(frgrahl)
Attached patch seamonkey-2.53.1-useragent.patch (obsolete) (deleted) — — Splinter Review

Proposed patch.

When "Advertise Firefox compatibility" is on, the additional indented checkbox is activated and allows to set "Look exactly as Firefox".

The correspond pref name is "general.useragent.compatMode.firefox-exact" .

Please, consider the preference's name and the String chosen -- whether my English is applicable for end users :)

Attachment #8711501 - Attachment is obsolete: true
Flags: needinfo?(frgrahl)

Just wrote a comment while you uploaded the patch :)

I think the checkbox should be "Look exactly as Firefox" (which describes its function more precisely).

If SeaMonkey and its version is removed from the UA it would be a genuine Fx UA. With a third checkbox "Advertise SeaMonkey" you could remove Fx and SeaMonkey "advertising" which even helps with some websites.

Whether this phrase should be localized, and how to do this -- provide a patch against l10n tree?
It is basically a string in the locales directory:
https://dxr.mozilla.org/comm-esr60/source/suite/locales/en-US/chrome/common/pref/pref-http.dtd#18

Missing strings will be reported to the localizers after checking into comm-central. Some jobs are running on the mozialla servers for this. We pic, them up later for our donwstream releases.

Well, I see Lightning uses "calendar.useragent.extra".
Is it likely that some other extensions add itselves to UA as well (ie. not UA-switching, but advertising of addons)?

I don't think so. Lightning is a special case. Should be made off by default now.

Will look at it later.

Comment on attachment 9121402 [details] [diff] [review] seamonkey-2.53.1-useragent.patch IanN maybe you can take a look at it too.
Attachment #9121402 - Flags: feedback?(iann_bugzilla)
Attachment #9121402 - Flags: feedback?(frgrahl)

(In reply to Frank-Rainer Grahl (:frg) from comment #23)

With a third checkbox "Advertise SeaMonkey" you could remove Fx and SeaMonkey "advertising" which even helps with some websites.

The idea of the current patch is to allow users to mimicry to FF for "full compatibility", by do not set it by default (since we don't wanna it by default).

Dropping even of FF, or some another UA parts, seems to be better handled by general.useragent.override mechanism (with site-specific).
Actually, I would like to test some websites where it might be useful -- are there some examples? (IMHO it could be Lightning-related issues etc...)

Comment on attachment 9121402 [details] [diff] [review] seamonkey-2.53.1-useragent.patch In general I agree with having this feature. In terms of how it is presented to the user, I would say that is a 3 way choice: a) Exactly like Firefox b) Compatible with Firefox c) No advertising of compatibility Whether that is done just in the prefs UI or it is done in the backend coding, I don't mind.
Attachment #9121402 - Flags: feedback?(iann_bugzilla) → feedback+

Considering how "competitors" resolve this issue their way, I think that the first my patch would be a choice.

Fe. Vivaldi now uses Chrome's UA string, see https://vivaldi.com/ru/press/releases/vivaldi-2-10-no-strings-attached/ and https://www.zdnet.com/article/vivaldi-to-change-user-agent-string-to-chrome-due-to-unfair-blocking/ for more info.

AFAIK Waterfox recently start to use FF60.

The first 4 year old patch provides the same, but preserves the choice, ie.

  • either SM only in UA (for ideal world);
  • or just FF only (for the real world).

Providing "FF + SM" (as it is now), in a hope that "FF" presence helps, does not help, since "SM" presence spoils all the things...

Comment on attachment 9121402 [details] [diff] [review] seamonkey-2.53.1-useragent.patch > In general I agree with having this feature. In terms of how it is presented to the user, I would say that is a 3 way choice: > a) Exactly like Firefox > b) Compatible with Firefox > c) No advertising of compatibility I am with IanN here. I am using option b) 99.9% of the time advertizing Firefox and SeaMonkey versions. Almost all websites I use work with this and for the others there is prefbar. With the full ua cache backout in Bug 1572290 this should now work for all of them too. I don't want to take b) out because I don't want to period :) and it would likely cause problems identifiying the real SeaMonkey version with future automatic updates and maybe add-ons. a) is the version of choice too for users who want to avoid being tracked. SeaMonkey sticks out like a sore tumb. Option c) as a general option is of not much use these days and will break some eggs so I think it can go. Spoofing the ua should be better here. Lightning appends its own version as a default choice. We should fix this but it is not 100% straight forward without modifying calendar code. We need to overwrite a pref with blank and add it to the one time migration code. This usually causes breakage not SeaMonkey in the ua.
Attachment #9121402 - Flags: feedback?(frgrahl) → feedback+

Lets not discuss this in Bug 1612722 so here it goes.

What would be the best way:
Disable Lightning advertising anyway when "exact FF" is set;
Just drop Lightning advertising for SM at all (not touching Lightning itself, just the correspond SM code)?
Then I can provide some work there.

My idea would be:
Then 3 choices as of now no Fx compatibility but set SeaMonkey (don't care much about this one), Fx + SeaMonkey (more or less like the default now) and Strict Fx compatibility. With the first 2 the advertize Lightning pref can stay active ´. When strict compatibility is choosen disable it and blank the pref.

no Fx compatibility but set SeaMonkey (don't care much about this one)

If we drop this option we only need 2 checkboxes One for strict compatibility and one for Lightning.

Attached patch seamonkey-2.53.1-useragent-v2.patch (obsolete) (deleted) — — Splinter Review

Useragent patch version 2.

Preferences-->Advanced-->HTTP Networking:
Radiogroup of two radio buttons plus indented autodisabled checkbox(es):

(.) Look exactly as Firefox
(.) Advertise SeaMonkey
    (v) Advertise Firefox compatibility
    (v) Advertise Lightning installation

(last is present when Lightning is enabled only, last two disabled when "Look exactly" is chosen)

Now "Look exactly as Firefox" prevents Lightning from spoiling UA string.

Flags: needinfo?(frgrahl)

Some notes about Lightning behaviour in UA context:

When provided with distribution, Lightning seems always enabled on a clean profile, with "Advertise Lightning" is on.

When user disable advertising, actually it empties "calendar.useragent.extra" string preference. If later Lightning will be re-enabled, it always overwrites such an ampty value by non-empty default, and this way 'Advertise Lightning" appears on again.

It looks dangerous, since:

  • it is very likely that "Advertise Lightning" appears ON, either after initial install, or by occasional re-enabling etc.;
  • when ON, an extra string is added to UA unconditionally;
  • such an extra string is not affected by site-specific useragent override mechanism at all;
  • such an extra string is not shown in "about:" page (UA looks "clean" instead).

Thus there is a need to mention in release notes that any playing with site-specific overrides (aka "general.useragent.override.google.com=UA-without-SM") must be accompanied with unchecking of "Advertise Lightning installation", else all efforts have no effect at all.

The reverting patch from bug #1572290 restores the use of "http-on-modify-request" observer (instead of "http-on-useragent-request").
It seems that "http-on-modify-request" is used in Lightning code to add its extra UA addon. IOW, if you don't feel any issues last years with site-specific overrides, it is likely because the Lightning addon code just not worked.

A fast easy work-around might be to set "calendar.useragent.extra" to value of "Mozilla" (or any other word already present in the normal UA string). Then Lightning deside that the addon already present and adds nothing. This way the "Advertise Lightning" checkbox remains active, but actually UA is not garbled by it.

Yes we should disable Lightning by default. I am just not sure if we should fiddling in calendar code. We could blank the pref when the user unchecks it and during migration also do this one time blanking if no user pref is set. Tomorrow is a status meeting. Need to ask what the others think. "http-on-modify-request was still sent but from a different location if I read the code correctly.

Flags: needinfo?(frgrahl)
Comment on attachment 9127751 [details] [diff] [review] seamonkey-2.53.1-useragent-v2.patch setting f? to not forget to look at it.
Attachment #9127751 - Flags: feedback?(frgrahl)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 1625750

After the Lightning issue is gone, the things have became much simpler now.

To leave only one checkbox for "FF+SM" vs. "FF only" and ignore rare "SM only" case looks good.

Whether a new pref name is needed, or still use the current one "general.useragent.compatMode.firefox", but with a different semantic?

What should be shown at the checkbox -- something like "Strict Firefox compatibility", or maybe just leave "Advertise Firefox compatibility" to avoid extra translating for l10n?

Flags: needinfo?(frgrahl)

Sorry for not tackling this sooner. But too much other things to do to get the new version out.

Thought about it already last week. I am happy with a single checkbox showing either "Strict Firefox compatibility" (no SeaMonkey and default unchecked) or "Advertize SeaMonkey" (Firefox plus Seamonkey so basically as is and checked as default). As stated I think cases where Firefox compatibility is completely dropped from the ua is doing more damage then helping so this case can imho be dropped and done via individual domain overrides by the user.

IanN should have the last word here.

Flags: needinfo?(frgrahl) → needinfo?(iann_bugzilla)
Attached patch seamonkey-2.53.1-useragent-v3.patch (obsolete) (deleted) — — Splinter Review

The patch v3.

One checkbox with "Strict Firefox compatibility" (instead of "Advertise Firefox compatibility").

The old pref name "general.useragent.compatMode.firefox" and the correspond booleans are gone, since we now always "advertise" FF (either "FF+SM" or "FF only").

The pref name chosen is "general.useragent.compatMode.strict-firefox", default "false".

Because of s/Advertise/Strict/, l10n changes needed.

Could be fine to see it in 2.53.2

Attachment #9121402 - Attachment is obsolete: true
Attachment #9127751 - Attachment is obsolete: true
Attachment #9127751 - Flags: feedback?(frgrahl)
Flags: needinfo?(frgrahl)
Blocks: 1572290
Flags: needinfo?(frgrahl)
Comment on attachment 9139594 [details] [diff] [review] seamonkey-2.53.1-useragent-v3.patch njsg suggested "Identify as Firefox" which I also like. https://freenode.logbot.info/seamonkey/20200408 Can't go into 2.53.2 becauee of the l10n change.
Attachment #9139594 - Flags: feedback?(iann_bugzilla)

(In reply to Frank-Rainer Grahl (:frg) from comment #37)

njsg suggested "Identify as Firefox" which I also like.

I hope "s/Strict Firefox compatibility/Identify as Firefox/" does not need extra new attachment here?

I hope "s/Strict Firefox compatibility/Identify as Firefox/" does not need extra new attachment here?

No. IanN needs to first take a look anyway. Last he told me he is still in favor of 3 options and not dropping "SeaMonkey without Firefox compatibility".

For a possible check in the patch needs a header and a be reformatted though. If you don't use hg in the future you might want to look into git-format-patch. We can do it but would like not to :)

(In reply to Frank-Rainer Grahl (:frg) from comment #39)

For a possible check in the patch needs a header and a be reformatted though. If you don't use hg in the future you might want to look into git-format-patch. We can do it but would like not to :)

Sorry, just no enough motivation for yet another bureaucracy. I guess I don't bother upstream too often, hence you can forgive me for that. ;)

Flags: needinfo?(iann_bugzilla)
Summary: Advertise exactly Firefox when compatMode.firefox is true → Update how Firefox compatibility is advertised
Attached patch Firefox strict mozilla patch (obsolete) (deleted) — — Splinter Review

This is the part of the patch for mozilla repo

Assignee: nobody → iann_bugzilla
Attachment #9139594 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #9139594 - Flags: feedback?(iann_bugzilla)
Attachment #9143441 - Flags: review?(frgrahl)
Attachment #9143441 - Flags: feedback?(dmitry)
Attachment #9143441 - Flags: approval-comm-release?
Attachment #9143441 - Flags: approval-comm-esr60?
Attached patch Firefox strict comm patch (obsolete) (deleted) — — Splinter Review

This is the comm part of the patch.
Rather than removing the existing pref, this adds a second pref for advertising strict Firefox compatibility and hides it behind a radiogroup for the UI.
I would say that boolean prefs are easier to deal with in the cpp backend and seems clearer, plus no messy pref migration code needed but happy to look at switching to a non-boolean pref if you want.

Attachment #9143442 - Flags: review?(frgrahl)
Attachment #9143442 - Flags: feedback?(dmitry)
Attachment #9143442 - Flags: approval-comm-release?
Attachment #9143442 - Flags: approval-comm-esr60?

Would help if I qrefresh before uploading, this now has the correct version with new pref defaulting to false if not present and Firefox being addition not just dependent on old pref being true.

Attachment #9143441 - Attachment is obsolete: true
Attachment #9143441 - Flags: review?(frgrahl)
Attachment #9143441 - Flags: feedback?(dmitry)
Attachment #9143441 - Flags: approval-comm-release?
Attachment #9143441 - Flags: approval-comm-esr60?
Attachment #9143443 - Flags: review?(frgrahl)
Attachment #9143443 - Flags: feedback?(dmitry)
Attachment #9143443 - Flags: approval-comm-release?
Attachment #9143443 - Flags: approval-comm-esr60?

(In reply to Ian Neal from comment #42)

I would say that boolean prefs are easier to deal with in the cpp backend and seems clearer, plus no messy pref migration code needed

Agree.

Rather than removing the existing pref, this adds a second pref for advertising strict Firefox compatibility and hides it behind a radiogroup for the UI.

Well, now:

( ) Strict Firefox compatibility
(.) Advertise Firefox compatibility
( ) No Firefox compatibility

Whether the "No Firefox compatibility" phrase will be correctly understood by the average user?

Maybe something like:

( ) Identify as Firefox
( ) Identify as SeaMonkey
(.) Identify as SeaMonkey and advertise Firefox compatibility

or even better:

( ) Identify as Firefox
(.) Identify as SeaMonkey
   [x] Advertise Firefox compatibility

Last variant has no logic mess as with "triple radiogroup and two booleans" (ie. clean corellation with about:config editing).

For moz part patch, isFirefox boolean can just be combined with mCompatFirefoxStrict like:

bool isFirefox = mAppName.EqualsLiteral("Firefox") || mCompatFirefoxStrict;
Flags: needinfo?(iann_bugzilla)
Attached patch seamonkey-2.53.2-useragent-comm-identify.patch (obsolete) (deleted) — — Splinter Review

Proposed comm part patch for "Identify as" variant.

Just to compare. Feel free to do anything with it :)

( ) Identify as Firefox
( ) Identify as SeaMonkey
(.) Identify as SeaMonkey and advertise Firefox compatibility

Just tested today. Works but have not looked at the patches yes. Like the "Identify" strings. They seem to be a little more non techie friendly. The checkbox idea is also ok but would need aditional logic. Imho not worth it.

Attached patch Firefox strict comm patch v1.1 (obsolete) (deleted) — — Splinter Review

Using "Identify as..." and fixing label/accesskey typo in xul

Attachment #9143442 - Attachment is obsolete: true
Attachment #9143483 - Attachment is obsolete: true
Attachment #9143442 - Flags: review?(frgrahl)
Attachment #9143442 - Flags: feedback?(dmitry)
Attachment #9143442 - Flags: approval-comm-release?
Attachment #9143442 - Flags: approval-comm-esr60?
Flags: needinfo?(iann_bugzilla)
Attachment #9143931 - Flags: review?(frgrahl)
Attachment #9143931 - Flags: approval-comm-release?
Attachment #9143931 - Flags: approval-comm-esr60?
Comment on attachment 9143443 [details] [diff] [review] Firefox strict mozilla patch v1.1 Review of attachment 9143443 [details] [diff] [review]: ----------------------------------------------------------------- Let it finally be.
Attachment #9143443 - Flags: feedback?(dmitry) → feedback+

In tomorrows/next WG9s build for public consumption and testing

Comment on attachment 9143443 [details] [diff] [review] Firefox strict mozilla patch v1.1 Works fine LGTM r/a+ for SeaMonkey release branches.
Attachment #9143443 - Flags: review?(frgrahl)
Attachment #9143443 - Flags: review+
Attachment #9143443 - Flags: approval-comm-release?
Attachment #9143443 - Flags: approval-comm-release+
Attachment #9143443 - Flags: approval-comm-esr60?
Attachment #9143443 - Flags: approval-comm-esr60+
Comment on attachment 9143931 [details] [diff] [review] Firefox strict comm patch v1.1 Works fine LGTM r/a+
Attachment #9143931 - Flags: review?(frgrahl)
Attachment #9143931 - Flags: review+
Attachment #9143931 - Flags: approval-comm-release?
Attachment #9143931 - Flags: approval-comm-release+
Attachment #9143931 - Flags: approval-comm-esr60?
Attachment #9143931 - Flags: approval-comm-esr60+
Attached patch Firefox strict comm patch v1.2 (deleted) — — Splinter Review

Carrying forward r/a

Attachment #9143931 - Attachment is obsolete: true
Attachment #9145043 - Flags: review+
Attachment #9145043 - Flags: approval-comm-release+
Attachment #9145043 - Flags: approval-comm-esr60+
Attached patch Help patch v1 (obsolete) (deleted) — — Splinter Review

A patch to change the help text to match the new UI. I've also removed "Advertise lightning installation" (or is this preference still present?).

Should the "or remote calendar services" be removed as well?

Attachment #9145205 - Flags: review?(iann_bugzilla)
Comment on attachment 9145205 [details] [diff] [review] Help patch v1 Looks good. I would drop "remote calendar services not working properly." From a compatibily standppoint it could be expanded with some more information but given the fact how many people actually seem to read release notes and help content possible a waste of time.
Attachment #9145205 - Flags: feedback+
Comment on attachment 9145205 [details] [diff] [review] Help patch v1 >+++ b/suite/locales/en-US/chrome/common/help/cs_nav_prefs_advanced.xhtml Sat May 02 06:00:36 2020 +0100 >@@ -498,18 +498,16 @@ > The identifier sent by &brandShortName; to all websites is used for > statistics about website usage but also sometimes to expose certain features > only to known browsers (a practice known as "sniffing"). Consequently, >- unchecking any of these boxes may result in websites or remote calendar >- services not working properly. >+ changing this option may result in websites or remote calendar >+ services not working properly. &brandShortName; can: Yes, please remove the "or remote calendar services" bit. > <ul> >- <li><strong>Advertise Firefox compatibility</strong>: If this is enabled, >+ <li><strong>Identify as &brandShortName;</strong></li> There should probably be something about what this does even if it is just "&brandShortName; will identify itself soley as &brandShortName; and not contain anything indicating compatibility with Firefox." >+ <li><strong>Identify as &brandShortName; and advertise Firefox compatibility</strong>: > &brandShortName; will identify itself as both &brandShortName; and also > compatible with Firefox. This allows websites that check for certain > browsers rather than certain functionality to work with &brandShortName;.</li> >- <li><strong>Advertise Lightning installation</strong>: This option is >- only available when the Lightning calendar extension is installed and >- activated. If this is enabled, &brandShortName; will add information on >- Lightning being installed and which version, thus calendaring websites >- and/or remote calendar services can customize their communication.</li> >+ <li><strong>Identify as Firefox</strong>: Do not mention >+ &brandShortName;, send a Firefox identifier instead.</li> These should be in the same order as in the preferences, so this should be first in the list. Also probably need to add something about why this option might be suitable in certain circumstances. f+ for the moment as I would like to see the next iteration of the patch. Thanks for the work so far.
Attachment #9145205 - Flags: review?(iann_bugzilla) → feedback+
Attached patch Help patch v1.1 (obsolete) (deleted) — — Splinter Review
Attachment #9145205 - Attachment is obsolete: true
Attachment #9145239 - Flags: review?(iann_bugzilla)
Comment on attachment 9145239 [details] [diff] [review] Help patch v1.1 Looking good, just formatting changes now. >+++ b/suite/locales/en-US/chrome/common/help/cs_nav_prefs_advanced.xhtml Sat May 02 06:00:36 2020 +0100 >@@ -498,18 +498,21 @@ > The identifier sent by &brandShortName; to all websites is used for > statistics about website usage but also sometimes to expose certain features > only to known browsers (a practice known as "sniffing"). Consequently, >- unchecking any of these boxes may result in websites or remote calendar >- services not working properly. >+ changing this option may result in websites >+ not working properly. &brandShortName; can: There can be up to 80 characters (including indentation) per line, so "not working properly." should go on the line above. > <ul> >- <li><strong>Advertise Firefox compatibility</strong>: If this is enabled, >+ <li><strong>Identify as Firefox</strong>: Do not mention >+ &brandShortName;, send a Firefox identifier instead. This >+ might be needed for websites which refuse to work when >+ &brandShortName; is mentioned in the identifier.</li> Again look at if some words can be moved up to previous lines to improve formatting. >+ <li><strong>Identify as &brandShortName;</strong>: >+ &brandShortName; will identify itself as &brandShortName;, >+ without mentioning Firefox.</li> Again look at if some words can be moved up to previous lines to improve formatting. f+ for the moment, thanks again for the work.
Attachment #9145239 - Flags: review?(iann_bugzilla) → feedback+

Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/97f8ec74862a
Update how Firefox compatibility is advertised - comm part. r=frg

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Attached patch Help patch v1.2 (obsolete) (deleted) — — Splinter Review
Attachment #9145239 - Attachment is obsolete: true
Attachment #9145318 - Flags: review?(iann_bugzilla)
Attached patch Help patch v1.3 (deleted) — — Splinter Review
Attachment #9145318 - Attachment is obsolete: true
Attachment #9145318 - Flags: review?(iann_bugzilla)
Attachment #9145325 - Flags: review?(iann_bugzilla)
Comment on attachment 9145325 [details] [diff] [review] Help patch v1.3 thanks, looks good r/a=me [Triage Comment]
Attachment #9145325 - Flags: review?(iann_bugzilla)
Attachment #9145325 - Flags: review+
Attachment #9145325 - Flags: approval-comm-release+
Attachment #9145325 - Flags: approval-comm-esr60+
Pushed by frgrahl@gmx.net: https://hg.mozilla.org/comm-central/rev/d7f83a840c2c Update help text for User-Agent preferences. r=IanN
Target Milestone: --- → seamonkey 2.74
Whiteboard: SM2.53.3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: