471333 - Unable to change the name of a web-based protocol handler

Status: NEW

(Firefox :: File Handling, defect)

Description

[Staś Małolepszy :stas]

It's currently not possible to change the name of a web-based protocol handler defined in region.properties.

There's a comment in this file that warns against this bug:

# increment this number when anything gets changed in the list below.  This will
# cause Firefox to re-read these prefs and inject any new handlers into the 
# profile database.  Note that "new" is defined as "has a different URL"; this
# means that it's not possible to update the name of existing handler, so 
# don't make any spelling errors here.

I tested with three builds:

1. 
First build can be downloaded from https://build.mozilla.org/tryserver-builds/2008-12-27_05:[e-mail]-handler1/
Contents of region.properties:
gecko.handlerService.defaultHandlersVersion=1
gecko.handlerService.schemes.mailto.0.name=Gmail
gecko.handlerService.schemes.mailto.0.uriTemplate=http://mail.google.com/mail/?extsrc=mailto&url=%s

2. 
First build can be downloaded from https://build.mozilla.org/tryserver-builds/2008-12-27_05:[e-mail]-handler2/
Contents of region.properties:
gecko.handlerService.defaultHandlersVersion=2
gecko.handlerService.schemes.mailto.0.name=Gmail
gecko.handlerService.schemes.mailto.0.uriTemplate=https://mail.google.com/mail/?extsrc=mailto&url=%s (note the https)

3. 
First build can be downloaded from https://build.mozilla.org/tryserver-builds/2008-12-27_05:[e-mail]-handler3/
Contents of region.properties:
gecko.handlerService.defaultHandlersVersion=3
gecko.handlerService.schemes.mailto.0.name=Google Mail
gecko.handlerService.schemes.mailto.0.uriTemplate=https://mail.google.com/mail/?extsrc=mailto&url=%s (note the https)

The case that's interesting from this bug's POV is the case of a profile created in build 2 opened in build 3. But I tested all 3 builds to get a more complete picture of the current behavior. I took a couple of screenshots from each build: new profiles, profile from build 1 opened in build 2, profile from build 1 opened in build 2 *and* 3, profile from build 1 opened in build 3 and profile from build 2 opened in build 3. All screenshots are available here:
http://informationisart.com/stas/mozilla/bugs/handlernames/

It seems that the current behavior is as follows:
* if only the URI changes then a new handler is added next to the old one,
* if both the URI and the name change then a new handler is added next to the old name (with the new name),
* if only the name changes then nothing is changed: the old handler (with the old name) is still available and the new name is not visible anywhere (screenshot: http://informationisart.com/stas/mozilla/bugs/handlernames/profile%20from%202%20opened%20in%203.png).

It would be good to fix this.

Comment 1

[Staś Małolepszy :stas]

Two related bugs for context: bug 392978 and bug 395277. 

Mike, do you know someone who could look into this?

Comment 2

[Staś Małolepszy :stas]

Dan, could you recommend anyone to look at this, please?

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

sdwilsh and dolske are possible candidates...

Comment 4

[Staś Małolepszy :stas]

sdwilsh, dolske, you have been tagged :) Can you offer your advice, please?

Comment 5

[Justin Dolske [:Dolske]]

Can't say I really have any; I'm not all that familiar with the code, and RDF is scary. :(