4 ms·

It’s pretty unclear to me whether people use this feature much. Two possibilities seem likely to me: 1. Very few people use this feature but a few vocal users

It’s pretty unclear to me whether people use this feature much. Two possibilities seem likely to me: 1. Very few people use this feature but a few vocal users who are particularly good at navigating bugtracking bureaucracy do use it and care deeply. 2. Of all Firefox users, a small percentage speak languages for which there are many non-ascii letters and a relatively large amount of pre-Unicode content online, and of those users a small percentage read niche (eg non-facebook and old) sites with broken character encoding. Both situations could probably lead to few uses of the menu in telemetry. Perhaps we should care more about users in the second category as they are perhaps more correlated with other things like location whereas the first set may be more uniformly distributed across the population. I think other points are also being disregarded: - ordinary users may find the feature cryptic and confusing. Or at least undiscoverable - dealing with character encoding and supporting the feature is painful (though the will still deal with it under the hood). Mozilla have limited resources and they (and Firefox users) want the browser to be successful and sustainable, and this means focusing resources on things that will make the browser easier to adopt and less confusing rather than chasing the short-lived gains from appeasing a small and stagnant pool of ‘power users’.

baybal2 5y ago
> Mozilla have limited resources and they (and Firefox users) want the browser to be successful and sustainable, To begin with, near nobody uses Firefox today. Very succesful, and sustainable. I have to pour heavy sarcasm here. It's honestly justly needed. Firefox went from 50%+ to sub 1% under the current leadership.
- yoasif_ 5y ago
  > To begin with, near nobody uses Firefox today. Very succesful, and sustainable. 215 million MAU is still a lot of people: https://data.firefox.com/dashboard/user-activity https://data.firefox.com/dashboard/user-activity
zozbot234 5y ago
> dealing with character encoding and supporting the feature is painful This feature is in no way "painful". It's a legitimate facility for dealing with non-Unicode, legacy content, and AFAICT it's not clear that it can be reliably replaced, even by a plugin. Any argument that the menu entry is "confusing" for most users can be addressed by hiding it behind an advanced preference setting, and I think this was done already.
- nneonneo 5y ago
  This feature should be replicable in a plugin: it just needs to inject an appropriate Content-Type header into a response (similarly to how user-agent extensions override the User-Agent headers in requests). A fancier plugin could even remember overrides per domain/path/site, making it even more useful than the original menu. To be clear, no such extension appears to exist yet, but it should be a matter of time before one is created.
  - nneonneo 5y ago
    ...and because it sounded easy, I went ahead and just did it: https://addons.mozilla.org/en-US/firefox/addon/override-text-encoding/ https://addons.mozilla.org/en-US/firefox/addon/override-text... The hardest part was doing all the UI bits, because I had to learn how to make a UI that would look halfway decent in the popup menu. But hey, it works!
    - hsivonen 5y ago
      The reason why this seems easy while the built-in feature got in the way of other changes is that the built-in feature dealt with more issues. For example: https://hsivonen.com/test/moz/never-show-user-supplied-content-as-utf-16.htm16le https://hsivonen.com/test/moz/never-show-user-supplied-conte...
marginalia_nu 5y ago
I still don't understand why someone would conflate whether something is frequently used with whether it is useful. Ask yourself: How often do you use the emergency number, how small is the percentage of the population that does in a day? Or even in a life? In the light of this, would you want it discontinued?
- deleted 5y ago
  [deleted]
- afavour 5y ago
  Right but that’s a matter of life or death. Let’s have some perspective. Another comparison is perhaps a small back road that no one ever drives down. How many years do you keep maintaining it before you close it off?
  - marginalia_nu 5y ago
    The point of the example is that there are things that are useful even if they are not frequently used. You simply cannot equate use with usefulness.
  - xg15 5y ago
    Wouldn't you have to ask where exactly the back road leads to?
zerocrates 5y ago
A complicating factor on the telemetry is that both this new "guess" option and its predecessor list are/were in the menubar View menu and have no way to be accessed through the "hamburger," so there wasn't a default-visible way to get to this functionality for Windows and Linux users. This is a pretty familiar pattern for controversial telemetry-based browser decisions, first making the feature more obscure or hidden, then later noting that few people are using it when justifying change/removal. How many users just abandoned a site they used to use or switched browsers is not captured in the telemetry (though options to switch to that still offer this feature are pretty thin on the ground). To be clear I don't think this was a "blind" telemetry decision; the developer seems to have done a pretty thoughtful and thorough analysis about it. But you see the pattern of such changes over the years and you start to imagine there's a thumb on the scale...
- dan-robertson 5y ago
  I’m not convinced that making it easier to find the menu of cryptic encodings would help. I think users would more easily discover that chrome correctly detects the encoding so perhaps the issue is just that the auto-detector needs to be a little better. Indeed if users were just going to chrome that would not show up in telemetry and so a low number would still not mean the the menu needs to be more visible. But this is all speculation really.
  - hsivonen 5y ago
    In cases where Chrome autodetects, Firefox autodetects, too. In the cases where you'd use the remaining menu item in Firefox, Chrome offers no recourse (apart from extensions).
- aftbit 5y ago
  Pro-tip: press Alt and you get the menu back, at least on my Linux.
  - yoasif_ 5y ago
    Windows as well.
grishka 5y ago
> It’s pretty unclear to me whether people use this feature much. People only dealing with languages that use the Latin script probably don't use it at all. But, speaking from my own experience with Russian, this feature is useful. Now that unicode is the default, text encoding problems are very rare, but they do sometimes still happen. Tools like this[1] were created out of necessity, not curiosity. [1] https://www.artlebedev.ru/decoder/ https://www.artlebedev.ru/decoder/
- zozbot234 5y ago
  There are multiple legacy encodings for text in Latin script - the only subset where encoding might not matter all that much is ISO 646, which is a subset of 7-bit US-ASCII. Even then EBCDIC, while relatively uncommon, is totally incompatible with even the ISO 646 subset.
serentty 5y ago
> dealing with character encoding and supporting the feature is painful (though the will still deal with it under the hood). Mozilla have limited resources and they (and Firefox users) want the browser to be successful and sustainable, and this means focusing resources on things that will make the browser easier to adopt and less confusing rather than chasing the short-lived gains from appeasing a small and stagnant pool of ‘power users’. Dealing with character encodings is indeed painful, but they are not dropping support for all of these legacy encodings. If they did, I am sure it would simplify things a lot in terms of maintenance, but they are too widespread in existing content to do that. Firefox will still use a legacy encoding if it detects it. All they are doing is removing the ability to tell Firefox that a website uses a certain encoding. The idea that this option is a maintenance burden is kind of hard for me to believe.
- xg15 5y ago
  I find it hard to believe as well, but he made some concrete mentions of other tickets that were apparently complicated by the ability to manually set encodings: > Additional non-user-facing benefit: The back end code for supporting the non-Automatic menu items got in the way of implementing bug 673087. Based on that experience, chances are that fixing bug 1701828 would be much easier if we first implemented the change proposed here.
  - zozbot234 5y ago
    Maybe, but if so users should still be able to submit a patch for reimplementing the feature properly, after these fixes land?

baybal2 5y ago

> Mozilla have limited resources and they (and Firefox users) want the browser to be successful and sustainable, To begin with, near nobody uses Firefox today. Very succesful, and sustainable. I have to pour heavy sarcasm here. It's honestly justly needed. Firefox went from 50%+ to sub 1% under the current leadership.

yoasif_ 5y ago
> To begin with, near nobody uses Firefox today. Very succesful, and sustainable. 215 million MAU is still a lot of people: https://data.firefox.com/dashboard/user-activity https://data.firefox.com/dashboard/user-activity

zozbot234 5y ago

> dealing with character encoding and supporting the feature is painful This feature is in no way "painful". It's a legitimate facility for dealing with non-Unicode, legacy content, and AFAICT it's not clear that it can be reliably replaced, even by a plugin. Any argument that the menu entry is "confusing" for most users can be addressed by hiding it behind an advanced preference setting, and I think this was done already.

nneonneo 5y ago
This feature should be replicable in a plugin: it just needs to inject an appropriate Content-Type header into a response (similarly to how user-agent extensions override the User-Agent headers in requests). A fancier plugin could even remember overrides per domain/path/site, making it even more useful than the original menu. To be clear, no such extension appears to exist yet, but it should be a matter of time before one is created.
- nneonneo 5y ago
  ...and because it sounded easy, I went ahead and just did it: https://addons.mozilla.org/en-US/firefox/addon/override-text-encoding/ https://addons.mozilla.org/en-US/firefox/addon/override-text... The hardest part was doing all the UI bits, because I had to learn how to make a UI that would look halfway decent in the popup menu. But hey, it works!
  - hsivonen 5y ago
    The reason why this seems easy while the built-in feature got in the way of other changes is that the built-in feature dealt with more issues. For example: https://hsivonen.com/test/moz/never-show-user-supplied-content-as-utf-16.htm16le https://hsivonen.com/test/moz/never-show-user-supplied-conte...

marginalia_nu 5y ago

I still don't understand why someone would conflate whether something is frequently used with whether it is useful. Ask yourself: How often do you use the emergency number, how small is the percentage of the population that does in a day? Or even in a life? In the light of this, would you want it discontinued?

deleted 5y ago
[deleted]
afavour 5y ago
Right but that’s a matter of life or death. Let’s have some perspective. Another comparison is perhaps a small back road that no one ever drives down. How many years do you keep maintaining it before you close it off?
- marginalia_nu 5y ago
  The point of the example is that there are things that are useful even if they are not frequently used. You simply cannot equate use with usefulness.
- xg15 5y ago
  Wouldn't you have to ask where exactly the back road leads to?

zerocrates 5y ago

A complicating factor on the telemetry is that both this new "guess" option and its predecessor list are/were in the menubar View menu and have no way to be accessed through the "hamburger," so there wasn't a default-visible way to get to this functionality for Windows and Linux users. This is a pretty familiar pattern for controversial telemetry-based browser decisions, first making the feature more obscure or hidden, then later noting that few people are using it when justifying change/removal. How many users just abandoned a site they used to use or switched browsers is not captured in the telemetry (though options to switch to that still offer this feature are pretty thin on the ground). To be clear I don't think this was a "blind" telemetry decision; the developer seems to have done a pretty thoughtful and thorough analysis about it. But you see the pattern of such changes over the years and you start to imagine there's a thumb on the scale...

dan-robertson 5y ago
I’m not convinced that making it easier to find the menu of cryptic encodings would help. I think users would more easily discover that chrome correctly detects the encoding so perhaps the issue is just that the auto-detector needs to be a little better. Indeed if users were just going to chrome that would not show up in telemetry and so a low number would still not mean the the menu needs to be more visible. But this is all speculation really.
- hsivonen 5y ago
  In cases where Chrome autodetects, Firefox autodetects, too. In the cases where you'd use the remaining menu item in Firefox, Chrome offers no recourse (apart from extensions).
aftbit 5y ago
Pro-tip: press Alt and you get the menu back, at least on my Linux.
- yoasif_ 5y ago
  Windows as well.

grishka 5y ago

> It’s pretty unclear to me whether people use this feature much. People only dealing with languages that use the Latin script probably don't use it at all. But, speaking from my own experience with Russian, this feature is useful. Now that unicode is the default, text encoding problems are very rare, but they do sometimes still happen. Tools like this[1] were created out of necessity, not curiosity. [1] https://www.artlebedev.ru/decoder/ https://www.artlebedev.ru/decoder/

zozbot234 5y ago
There are multiple legacy encodings for text in Latin script - the only subset where encoding might not matter all that much is ISO 646, which is a subset of 7-bit US-ASCII. Even then EBCDIC, while relatively uncommon, is totally incompatible with even the ISO 646 subset.

serentty 5y ago

> dealing with character encoding and supporting the feature is painful (though the will still deal with it under the hood). Mozilla have limited resources and they (and Firefox users) want the browser to be successful and sustainable, and this means focusing resources on things that will make the browser easier to adopt and less confusing rather than chasing the short-lived gains from appeasing a small and stagnant pool of ‘power users’. Dealing with character encodings is indeed painful, but they are not dropping support for all of these legacy encodings. If they did, I am sure it would simplify things a lot in terms of maintenance, but they are too widespread in existing content to do that. Firefox will still use a legacy encoding if it detects it. All they are doing is removing the ability to tell Firefox that a website uses a certain encoding. The idea that this option is a maintenance burden is kind of hard for me to believe.

xg15 5y ago
I find it hard to believe as well, but he made some concrete mentions of other tickets that were apparently complicated by the ability to manually set encodings: > Additional non-user-facing benefit: The back end code for supporting the non-Automatic menu items got in the way of implementing bug 673087. Based on that experience, chances are that fixing bug 1701828 would be much easier if we first implemented the change proposed here.
- zozbot234 5y ago
  Maybe, but if so users should still be able to submit a patch for reimplementing the feature properly, after these fixes land?