All users were logged out of Bugzilla on October 13th, 2018
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:email@example.com/ 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:firstname.lastname@example.org/ 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:email@example.com/ 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.
Two related bugs for context: bug 392978 and bug 395277. Mike, do you know someone who could look into this?
Dan, could you recommend anyone to look at this, please?
sdwilsh and dolske are possible candidates...
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. :(
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.