Closed Bug 423776 Opened 12 years ago Closed 12 years ago

Wrong action shown for protocol in prefs, can't get back to OS default

Categories

(Core Graveyard :: File Handling, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9

People

(Reporter: Dolske, Assigned: Dolske)

References

Details

Attachments

(1 file)

First reported in bug 413630 comment 37: "I have a problem after this fix. In the Preferences -> Applications, "Use sylpheed(default)" is displayed as Action but it doesn't exist in the pull down list."

I see the same thing (but didn't verify it was caused by 413630). What's interesting is that when the "mailto" entry isn't selected, it correctly shows the OS default ("Use Evolution", for me). But if you click once to select the entry, it comes a <select> with "Always Ask" shown. Click once on another entry, and it reverts to "Use Evolution". Things seem to work correctly; clicking a mailto link still launches Evolution without prompting.

Unfortunately, if you end up selecting an entry from the <select>, it sets it to that value, acts normally, and you can't get the OS default one back. :(

Seems like this might be bug in how the preferences code is building up what it shows in the UI (or the info it's getting is quirky). Probably Linux only, didn't see this on OS X.
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Target Milestone: --- → Firefox 3
I don't think 413630 actually broke this, but since mailto didn't show up before it probably wasn't visible. An older (pre-413630) build run on a new profile (with the 413630 injected mailto defaults) shows that same problem.

Looks like the problem is that nsMIMEInfoUnix::GetHasDefaultHandler returns false, and so the prefpane's applications.js rebuildActionsMenu() doesn't create an entry for the OS default handler.

The solution should be to either fix GetHasDefaultHandler to work in this case, or have rebuildActionsMenu() not use hasDefaultHandler. With all the overloaded semantics things have, I'm not sure which approach is right yet. Bug 273524 just recently added the unix-specific implementation of this method.
Blocks: 273524
Whiteboard: [needs status update]
Whiteboard: [needs status update]
Attached patch Patch v.1Splinter Review
I went with the first approach from my last comment... It seems like GetHasDefaultHandler() *should* be returning |true|, so that's what should be fixed.

This patch fixes the bug described here, and as a side effect seems to make using evolution-webcal suddenly possible... Before, the only available action for "webcal" was 30Boxes (the protocol handler we ship). With the patch evolution-webcal shows up too, and works.

The only problem is that I don't quite understand why that works. :-( It seems like the unix-specific implementation of GetHasDefaultHandler() was the wrong thing to do for bug 273524... I'd expect the default implementation from nsMIMEInfoImpl (which just looks at mDefaultApplication / mDefaultAppDescription) to be fine, and whatever GnomeVFS-fu was needed for 273524 to have been done in the code that sets those two members.

The fallback case added by this patch makes would seem sensible for mailto, it's why webcal is working better now that's strange. I don't understand this spaghetti code, or what's expected to happen here, but it seems like things work. :-/

Biesi / Mike H, any comments?
Attachment #313995 - Flags: review?(cbiesinger)
Attachment #313995 - Flags: review?(cbiesinger) → review+
Flags: blocking-firefox3+
Product: Firefox → Core
QA Contact: file.handling → file-handling
Target Milestone: Firefox 3 → mozilla1.9
(move to Core cleared blocking-firefox3 flag, asking for blocking1.9)
Flags: blocking1.9?
webcal is fixed because that sets mType to webcal (and mClass to eProtocolInfo), so GetAppForMimeType wouldn't do the right thing there. we probably shouldn't try to call it in that case...

But yeah, removing this function and relying on mDefaultDescription sounds good to me. http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/unix/nsGNOMERegistry.cpp#133 does set mDefaultDescription.
After discussing with dmose, it seems best to land this patch as-is. I've filed bug 427879 to later take a look at cleaning up things more deeply (which entails more risk).
Checked in.

Checking in uriloader/exthandler/unix/nsMIMEInfoUnix.cpp;
  new revision: 1.5; previous revision: 1.4

[Leaving blocking nom -- it was +'d before being moved to Core]
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to comment #0)
I'm verifying this bug using build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041604 Minefield/3.0pre

Here's what I've tested:
> I see the same thing (but didn't verify it was caused by 413630). What's
> interesting is that when the "mailto" entry isn't selected, it correctly shows
> the OS default ("Use Evolution", for me). 
Evolution is still the default for the OS, and is selected properly when you first run firefox on a new profile.

> But if you click once to select the
> entry, it comes a <select> with "Always Ask" shown. 
Now, if you select it, it maintains the "Evolution (Default)" setting.  This is good.

> Click once on another
> entry, and it reverts to "Use Evolution". 
Clicking on another entry and it stays on "use Evolution".  This is good.

> Things seem to work correctly;
> clicking a mailto link still launches Evolution without prompting.
Yep, verified that still works.

> 
> Unfortunately, if you end up selecting an entry from the <select>, it sets it
> to that value, acts normally, and you can't get the OS default one back. :(
I selected the Yahoo webmail handler, verified that it launched Yahoo, and then re-selected Evolution in the preferences window and clicked another mailto link.  This second mailto link launched evolution again, and Evolution was again listed in the preferences window as the default handler.

So, it seems like this is working as it should be now.

--> VERIFIED.

Status: RESOLVED → VERIFIED
Duplicate of this bug: 430793
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.