GNOME Bugzilla – Bug 735559
Remove page encoding dialog
Last modified: 2015-12-07 11:20:08 UTC
I think we should remove the setting to set page encoding from the header bar menu. This also entails removing the page encoding dialog. Rationale: it's a . Worth mentioning that it's not possible to change the page encoding in Firefox, and it seems odd that we have a more advanced feature than Firefox does. However, there are some cases where it may be needed, for example, Reinout says: "I use it sometimes on Gnome changelogs, for example http://ftp.gnome.org/pub/gnome/sources/epiphany/3.12/epiphany-3.12.1.changes . It's served in the wrong encoding (try looking up Matej Urbančič in that changelog)." Maybe we should default to UTF-8 for plain text documents, or see how gedit detects the document's encoding. This is a distinct issue from bug #734381, which is the removal of the preference for setting the default page encoding when the document does not specify one (which Firefox DOES allow, but which seems even less useful).
(In reply to comment #0) > Rationale: it's a . It's a confusing technical detail that's of no relevance to users unless the page sets the encoding incorrectly, in which case it will be broken in other browsers too and not just Epiphany. (But this is considering HTML pages only.)
I think we needs this option somewhere, for the cases we still needs this. Also, I think we not needs to look always what firefox does. I see in a lot of bugs you say what firefox does. we needs to do what we needs, not what firefox does or not.
We don't need to set page encoding on HTML pages (it's set by the document) which is what we care about 95% of the time. For the rest of the time: "Maybe we should default to UTF-8 for plain text documents, or see how gedit detects the document's encoding."
There are still cases like this http://www16.big.or.jp/~zun/html/th14dl.html which uses Shift-JIS and is HTML.
Firefox can display that automatically, so we should be able to as well. I'm not sure how Firefox can, though, since that page doesn't declare a character set....
Google Chrome has the same issue as Epiphany. I tested it with other pages as well, like: http://www.interdb.jp/techinfo/algorithm/list_lockfree2.html So, until Epiphany/webkitgtk is able to detect encoding when it's not declared, the encoding menu should not be removed IMHO.
Seems we have consensus to keep this dialog until such time that WebKit can automatically detect page encoding.