'Select Helper Application' dialog for mailto: protocol scheme: list empty with installed applications and available webapps
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
People
(Reporter: aryx, Unassigned)
References
Details
Firefox Nightly 67.0a1 20190313100914 on Windows 8.1, Firefox ESR 60.5.2esr
The 'Select Helper Application' dialog for the mailto: protocol scheme has the list with installed applications and available webapps empty (the items already shown in the dropdown should also be found here - that's what happens for .pdf)
There is an 'undefined' label below 'mailto', not sure if this is related.
Steps to reproduce:
- Open Options/Preferences > General > Applications
- For mailto, open the dropdown and click on "Use other..."
Actual result:
List empty.
Expected result:
List populated with handlers for mailto:
|
||
Comment 1•7 years ago
|
||
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #0)
Firefox Nightly 67.0a1 20190313100914 on Windows 8.1, Firefox ESR 60.5.2esr
So not a recent regression, then? Did you try any other recent releases?
|
Reporter | |
Comment 2•7 years ago
|
||
Same behavior with 65.0.2 and 66.0 RC1 (20190311211048). Even reproducible with ESR 24, dropping regression keyword. Possible the many Thunderbird installations cause unexpected behavior.
|
||
Updated•7 years ago
|
|
|
Reporter | |
Comment 4•7 years ago
|
||
No errors in the console. From debugging:
mailto: doesn't have possibleLocalHandlers when called at https://searchfox.org/mozilla-central/rev/7abb9117c8500ed20833746c9f8e800fce3a4688/toolkit/components/apppicker/content/appPicker.js#59
The protocol handler constructor gets called at https://searchfox.org/mozilla-central/rev/7abb9117c8500ed20833746c9f8e800fce3a4688/browser/components/preferences/in-content/main.js#1561
The handler wrapper constructor used for protocols doesn't implement that: https://searchfox.org/mozilla-central/rev/7abb9117c8500ed20833746c9f8e800fce3a4688/browser/components/preferences/in-content/main.js#2619
PDF is special: https://searchfox.org/mozilla-central/rev/7abb9117c8500ed20833746c9f8e800fce3a4688/browser/components/preferences/in-content/main.js#1504
|
|
||
Comment 5•7 years ago
|
||
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #4)
No errors in the console. From debugging:
mailto: doesn't have possibleLocalHandlers when called at https://searchfox.org/mozilla-central/rev/7abb9117c8500ed20833746c9f8e800fce3a4688/toolkit/components/apppicker/content/appPicker.js#59
This is pretty surprising... it seems to suggest no mail apps are registered on your system, see code in https://searchfox.org/mozilla-central/source/uriloader/exthandler/win/nsMIMEInfoWin.cpp#506 . Is that really true, or is there another bug somewhere in there?
|
||
Updated•7 years ago
|
|
|
Reporter | |
Comment 6•7 years ago
|
||
Brain dump of the reverse call stack:
appPicker.js
appPickerLoad
mimeInfo.possibleLocalHandlers is not defined and early return
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/toolkit/components/apppicker/content/appPicker.js#63
appPicker.xul
loaded by
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#2145
passes in the the param mimeInfo which doesn't have possibleLocalHandlers defined
params.mimeInfo = handlerInfo.wrappedHandlerInfo;
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#2128
var handlerInfo = this.selectedHandlerListItem.handlerInfoWrapper;
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#2126
this.selectedHandlerListItem = handlerListItem;
https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/main.js#1589
let handlerListItem = this._list.selectedItem &&
HandlerListItem.forNode(this._list.selectedItem);
https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/main.js#1580
static forNode(node)
https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/main.js#2548
return gNodeToObjectMap.get(node);
https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/main.js#2549
gNodeToObjectMap.set(this.node, this);
https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/main.js#2570
That gets set up in _rebuildView
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1654
var visibleTypes = this._visibleTypes;
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1662
this._visibleTypes.push(handlerInfo);
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1636
let handlerInfo = this._handledTypes[type];
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1617
For protocols everything except pdf and plugins set in _loadApplicationHandlers at
this._handledTypes[type] = handlerInfoWrapper;
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1562
handlerInfoWrapper = new HandlerInfoWrapper(type, wrappedHandlerInfo);
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1561
Just sets the argument as property:
this.wrappedHandlerInfo = handlerInfo;
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#2622
for (let wrappedHandlerInfo of gHandlerService.enumerate()) {
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#1554
gHandlerService: ["@mozilla.org/uriloader/handler-service;1", "nsIHandlerService"],
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/browser/components/preferences/in-content/main.js#25
enumerate() {
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/HandlerService.js#247
This is the important difference:
MIME types handlers are created by gMIMEService.getFromTypeAndExtension
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/HandlerService.js#250
Protocol handlers by gExternalProtocolService.getProtocolHandlerInfo
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/HandlerService.js#250
For the latter:
return target[name] || target._handlerInfo[name];
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/HandlerService.js#274
return this._handlerInfo = gExternalProtocolService.getProtocolHandlerInfo(type);
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/HandlerService.js#269
nsExternalHelperAppService::GetProtocolHandlerInfo(
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/nsExternalHelperAppService.cpp#1094
GetProtocolHandlerInfoFromOS(aScheme, &exists, aHandlerInfo);
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/nsExternalHelperAppService.cpp#1094
nsMIMEInfoWin* handlerInfo =
new nsMIMEInfoWin(aScheme, nsMIMEInfoBase::eProtocolInfo);
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/win/nsOSHelperAppService.cpp#475
Here the situation looks unexpected to me:
LaunchWithFile expects eMIMEInfo and doesn't handle eProtocolInfo
https://searchfox.org/mozilla-central/rev/73e1da0906e711285c15b0fa5472263c01cbd3f2/uriloader/exthandler/nsMIMEInfoImpl.cpp#255
With the VS debugger, stepping always leads to nsMIMEInfoImple.cpp (and not nsMIMEInfoWin.cpp).
For the record, this will dump the protcol web handlers if run on about:preferences:
var wrappedHandlerInfo = gMainPane.selectedHandlerListItem.handlerInfoWrapper.wrappedHandlerInfo;
var fileList = wrappedHandlerInfo.possibleApplicationHandlers;
for (var idx = 0; idx < fileList.length; idx++) {
var file = fileList.queryElementAt(idx, handler);
try {
console.log(file);
} catch (err) {
continue;
}
}
|
|
||
Comment 7•7 years ago
|
||
So I was confused between possibleApplicationHandlers and possibleLocalHandlers.
I'm not sure this dialog was ever supposed to work for protocol handlers? Is it possible to open it on e.g. Firefox 3/4 on Windows 7?
I also don't see code for enumerating system/app protocol handlers, just for launching the default one... it's possible I'm missing it of course...
|
|
||
Comment 8•6 years ago
|
||
I removed the "undefined" bit in bug 1593806.
|
||
Updated•3 years ago
|
Mailto is no longer listed in applications. Mailto should be a standard application in Settings:Applications. This is a serious problem.
|
||
Comment 10•3 years ago
|
||
Turns out that there are 6 copies of the handlers.json file in my profile. 5 are marked corrupt. In order to restore "mailto" as an option, I had to create a new virgin profile and copy the handlers.json from it to my preferred profile. So: (1) this appears to be a common problem (2) surely you don't expect normal users to find and copy the handlers.json file (esp. correctly). (3) what is corrupting the handlers.json in the first place?
I "left behind" some apps in the old json that I will probably miss in the near future. Some %^&* installed apps probably modified the json and screwed it up. How do we prevent that? Could an app have removed mailto from my handlers.json? (of course)
Description
•