Closed Bug 282269 Opened 15 years ago Closed 12 years ago

Release note how to turn IDN display back on

Categories

(Core :: Networking, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: gerv, Assigned: asa)

Details

(Keywords: relnote)

It would be good to ship a simple XPI for re-enabling IDN by flipping the
network.enableIDN pref. Such an XPI should put up a warning dialog explaining
the current spoofing dangers before allowing itself to be installed.

Darin: this is assigned to you merely because you wrote the one which turns the
pref off, and so it was suggested you might be able to write the opposite
without too much difficulty. :-)

Gerv
Flags: blocking1.8b2?
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
blocking the release
Flags: blocking1.8b2?
Flags: blocking1.8b2+
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
Some concerns I see for whoever takes this:

-files in XPI should be in mozilla source (likely extensions/idn or similar)
-must be designed to be localizable
    -those who need localized versions are most likely to want this
    -install.rdf (for Firefox) must be build-time localizable (bug 257155)
-must work in Firefox *and* SeaMonkey (incl. l10n)
-should extension offer toggling or only enabling of IDN?
    -toggle is more UI (bloaty)
    -enable-only makes it more difficult to tell user how to disable IDN
     should he wish to do so (which is probably wanted, for safety's sake)

I was considering tackling this until I thought about the above issues.  Anyone
else who considers taking this should probably consider them too.
Hmm... an XPI is certainly one way to go.  Mozilla.org could probably also host
a signed-script to do this as well.

This also doesn't seem to belong in the networking component, but whatever ;-)
See companion bug 282270 for the thing this XPI will actually do. I don't think
it needs to add any browser UI, or allow for people re-disabling IDN. It should
just pop a (localisable) warning box, and then flip the "network.enableIDN2"
pref to true.

Gerv
I don't understand the need for an XPI to enable IDN.  People can toggle the
preference if they care, and if some enterprising person wishes to make a user
friendly XPI then they can do so.  Why not put up a web page that gives users
steps to enable the pref using about:config, and explain the risks on that page?
 I don't have gobs of free time, so it'd be great if someone else would take on
the task of putting up such a page.  Gerv?
Given the new approach of showing raw punycode and not actually turning off IDN
we don't need a XPI for the security releases. Un-breaking things would be
important, un-uglifying less so. We can decide whether or not to do an official
XPI later, or leave that up to the extension community.

One thing we *should* do is release note the IDN changes and how to revert the
punycode display back to IDN for those who want it and accept the risks.

Morphing bug, ->Asa
Assignee: darin → asa
Flags: blocking1.8b2+
Flags: blocking1.8b+
Flags: blocking-aviary1.1+
Keywords: relnote
Summary: Write XPI for turning on network.enableIDN → Release note how to turn IDN display back on
we dont need an xpi to re-enable it. put the about:config instructions on the
mozilla help tips and tricks page.
On http://www.mozilla.org/products/firefox/releases/ it is written:

     International Domain Names are now displayed as punycode.
     (To show International Domain Names in Unicode, set
      the "network.IDN_show_punycode" preference to false.)

However, in my "about: config" I see network.IDN_show_punycode defaulted to
boolean true, and network.enableIDN user set to boolean false.

So Release Notes seem misleading: to enable IDN, I should toggle
network.enableIDN to true, that's all.

Is it the same bug or should I file a separate one?



My browser is

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223
Firefox/1.0.1
Hmm... Now I see that network.IDN_show_punycode is a separate problem, and it
has to be in Release Notes as well... But, then, why there is no hint in Release
Notes about network.enableIDN? Now I'm really confused.
network.enableIDN defaults to true and always has. if it is false, you set it to
false explicitly. of course to enable IDN you must set it to true again.
This bug is obsolete.

Gerv
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.