All users were logged out of Bugzilla on October 13th, 2018

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

NEW
Unassigned

Status

()

10 years ago
2 years ago

People

(Reporter: stas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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:16-smalolepszy@mozilla.com-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:17-smalolepszy@mozilla.com-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:17-smalolepszy@mozilla.com-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.
(Reporter)

Comment 1

10 years ago
Two related bugs for context: bug 392978 and bug 395277. 

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

Comment 2

10 years ago
Dan, could you recommend anyone to look at this, please?
sdwilsh and dolske are possible candidates...
(Reporter)

Comment 4

10 years ago
sdwilsh, dolske, you have been tagged :) Can you offer your advice, please?
Can't say I really have any; I'm not all that familiar with the code, and RDF is scary. :(

Updated

2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.