Closed Bug 633941 Opened 9 years ago Closed 9 years ago

Mac OS X "Open with..." / double-click on "web" file horked (browser launches without actually loading the file).

Categories

(Firefox :: Shell Integration, defect, major)

All
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- .x+

People

(Reporter: glazou, Assigned: jaas)

References

Details

(Whiteboard: [4rc])

Attachments

(1 file)

(cannot find a previously reported bug on same topic for FF4 so filing a new
 bug)

Jag (I'll cc him) can reproduce the bug too.
In my case: FF4b12pre, OS 10.6.6, tried both fr-FR and en-US OS locales. Tested in both 32 and 64bits.

Steps to reproduce:

1. have a HTML document on your Mac OS X desktop; make sure FF4 is NOT
   ALREADY RUNNING
2. context-click on it and use the "Open with" menu to open it with FF4

Expected result: FF4 launches and browses the requested document
Actual result: FF4 launches but does not browse the requested document

FWIW, it's a regression from FF3.6.x that works fine here.
FWIW too, my editor BlueGriffon being based on the same trunk suffers from the same issue.
asking for blocking2.0, this is a real bummer on OS X.
blocking2.0: --- → ?
This sucks, but I wouldn't hold the release for it.
blocking2.0: ? → .x
(In reply to comment #2)

> This sucks, but I wouldn't hold the release for it.

Would you hold the release for same loss of function on Windows?
At this point, I'm not sure.
Well. I'm surprised we could let go a version of FF4 without a feature that's
been in *all* versions of Firefox and Netscape before it, and that a
fraction of the public relies on... Does not make sense to me.
I'm probably doing something wrong, but this also seems broken for just double clicking a HTML file. Tested with "Show my home page", "Show a blank page", "Show my windows and tabs from last time".
Does someone have time to find a regression window for this issue?
I can't get "Open With ..." to work with FF 3.6.13, either (testing on
OS X 10.5.8) -- though this may have something to do with the number
of copies of FF I have "installed".

This is (apparently) a very old problem, but it doesn't seem to have
been reported before.  So I suspect there aren't many people who use
"Open With ...".  (I never use it myself, which is why I've never
noticed it.)

Which isn't to say that we shouldn't fix it.  But it's a good reason
not to block the FF 4 release.

It's too bad we weren't aware of this testcase when we (Josh and I)
were working on bug 531552 :-(
Tested using "Right-click -> Open With ..."

Works in 4.0b8, broken in 4.0b10.

In 4.0b8 it mostly works, in that it loads the file in a new tab and opens a bonus (blank for me) new window. If I first see the Profile Manager or "Checking for Compatibility of Add-Ons" dialog it doesn't work in 4.0b8 either (separate bug).
The extra window business was what was fixed by the patch(es) for bug
531552 -- which has landed both on the 1.9.2 branch (FF 3.6.X, bug
531552 comment #128) and the trunk (FF 4, bug 531552 comment #166).

And this bug doesn't happen with FF 3.6.7 (which doesn't contain the
patch for bug 531552).  So presumably this bug was (at least partly)
caused/triggered by the patches for bug 531552.

But any fix for this bug is likely to have other repercussions, and
we're very close to the FF 4 release.  So I still don't think this bug
should block FF 4.
(In reply to comment #8)
> I can't get "Open With ..." to work with FF 3.6.13, either (testing on
> OS X 10.5.8) -- though this may have something to do with the number
> of copies of FF I have "installed".

It works for me with 3.6.13. Interesting you mentioned bug 531552, that's the one that came to mind when I saw this issue.

(In reply to comment #9)
> Tested using "Right-click -> Open With ..."
> 
> Works in 4.0b8, broken in 4.0b10.

This is within the window that bug 531552 was landed. I have a feeling that it may be a regression from that bug. Can we check if this patch caused the regression?
http://hg.mozilla.org/mozilla-central/rev/72d9ec027cba
Broken in 4.0b9. Looking at that patch now.
(In reply to comment #8)
> I can't get "Open With ..." to work with FF 3.6.13, either (testing on
> OS X 10.5.8) -- though this may have something to do with the number
> of copies of FF I have "installed".

Yes. It works just fine for me with 3.6.13 on OS 10.6.6.
Reverting that patch from bug 531552 makes the "Open With..." test case work.

ProcessPendingGetURLAppleEvents() seems to somehow be causing us to never see the "openFile" message.

Commenting out the call to PPGUAE() gets us "openFile" again, but it happens (long?) after we're done with |SetupMacCommandLine() ... cmdLine->Run()| in XRE_Main(), so it falls back to creating a new command line and running that, which gets us the bugs that patch was trying to fix.

If I restore the kAEOpenDocuments bits from an earlier version of that patch (and enable PPGUAE() again of course) then Open With works as it should. In fact, it loads the page in a new tab, woot!

I believe initially it (along with some other code related to event processing) was left out because it was suspected in increasing Ts noise (bug 584273) and it was thought this code wasn't essential. Looks like it is, so I'm kinda hoping we'll take it and live with it.
Summary: Mac OS X "Open with..." horked → Mac OS X "Open with..." / double-click on "web" file horked (browser launches without actually loading the file).
Code written by Josh Aas, see bug 531552 comment 111.

Josh, does the default implementation for openFiles: iterate and call openFile:? Or would that also be covered with the event handling in this patch?
I hope to get to this bug later this week -- after I deal with bug 627649.
(In reply to comment #15)
> Created attachment 512440 [details] [diff] [review]
> Patch to handle double-click-to-launch / Open With... properly (code by Josh
> Aas)
> 
> Code written by Josh Aas, see bug 531552 comment 111.

Confirming that with this patch in, BlueGriffon now corectly sees the file://
URL of the file opened through an "Open with" preceeded by a "-url" in the
command line :-)
Gotta tell you my story:

- I initiated bug 574016 (JUN 2010), flagged as a dupe of 531552.
- I researched already posted comments on 531552, and found it represented my issues accurately.
- Comment 17 mentioned the issue in this bug (633941) for an INTEL platform.
- I tested my platform (PowerBook PPC G4, OSX 10.5.8) to see if I had that problem, too; it did and I mentioned it (for PPC) in comment 20 (bug 531552).
- I sat on my heels and waited to see if it would be resolved along with the initial 531551 problems.

[To the best of my knowledge, the last FF version that did NOT experience this bug (633941) was 3.5.10]

- The initial bug 531552 issues were resolved, I believe for PPC, in FF 3.6.9, but still exhibited the bug mentioned in this bug (633941) for a PPC.
- Since at the issue of FF 3.6.9 Bug 531552 was not flagged as resolved, I continued to wait, thinking this issue was still being addressed.

Daniel (comment 5): this feature has not worked for PPC since FF 3.5.10.

jag (comment 6): since FF 3.5.10 (PPC) has been broken for double-click in Finder, and for "Open with...) in contextual menu (with FF closed, opens only a blank page).

Steve (comment 8): As a webmaster, I used it all the time to verify my changes prior to publishing to a web server; I've had to do work-arounds which were more time-consuming than dbl-clicking; this issue was mentioned in bug 531552, comments #17 (INTEL) and #20 (PPC).

I really wish this could be fixed for PPC before Mozilla no longer supports my platform. I maybe should mention there was some Apple update support for OSX 10.5.8 (PPC) some time within the last couple of months. I do not know if Apple has officially announced it has terminated support for this, apparently the last, iteration of OSX 10.5.8 for PPC. 

Richard
Did a bit of testing using Open with... to get 3.6.13. I'm on 10.6.6.

With 3.6.13, this fails (document is not opened) IFF a Master Password is set. If no master password is set, the document is opened correctly.

Minefield is broken, Master Password is no factor.
(In reply to comment #19)
> Did a bit of testing using Open with... to get 3.6.13. I'm on 10.6.6.
> 
> With 3.6.13, this fails (document is not opened) IFF a Master Password is set.
> If no master password is set, the document is opened correctly.
> 
> Minefield is broken, Master Password is no factor.

3.6.13 fails "open with..." and double click on PPC (10.5.8) w/o master password.
Do I need to initiate a new bug for this issue, except for PPC vice INTEL? or will it be flagged as a dupe of this bug?

Or, if I don't initiate a new bug for PPC, will my issue be ignored because this bug is about INTEL?
The people who know more about how our Mac OS X facing code works are quite busy fixing other bugs so Mozilla can ship Firefox 4. It might be a while before they get around to this bug, or answering your question.

The changes in this patch have been on the 1.9.2 branch since August 2010, so as far as I can tell they should be in 3.6.13. Sounds like whatever is going on for you is a different bug. I think there's a known issue with us not passing the Open With / double-click paths along when the Profile Manager opens when you launch Firefox, but if it's not that, please file a new bug.
Assignee: nobody → joshmoz
(In reply to comment #15)

> Josh, does the default implementation for openFiles: iterate and call
> openFile:? Or would that also be covered with the event handling in this patch?

I don't know for sure, but I don't recall it ever mattering so my guess is that it does something reasonable, like what you suggest.
Comment on attachment 512440 [details] [diff] [review]
Patch to handle double-click-to-launch / Open With... properly (code by Josh Aas)

If this fixes the problem I don't see any reason not to try it in the code.
Attachment #512440 - Flags: review+
Attachment #512440 - Flags: approval2.0+
Comment on attachment 512440 [details] [diff] [review]
Patch to handle double-click-to-launch / Open With... properly (code by Josh Aas)

r=jag (since this is really just josh's code that got backed out)
Attachment #512440 - Flags: review+
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/54d33cb3ebef
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Verified using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12) Gecko/20100101 Firefox/4.0b12.
Status: RESOLVED → VERIFIED
Able to reproduce on Mac 10.5.8 using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0) Gecko/20100101 Firefox/4.0.
(In reply to comment #28)
> Able to reproduce on Mac 10.5.8 using Mozilla/5.0 (Macintosh; Intel Mac OS X
> 10.5; rv:2.0) Gecko/20100101 Firefox/4.0.

Reopening
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whiteboard: [4rc]
WFM using the release candidate. I'm going to resolve this, and you can open a new bug if necessary, since this is fixed for most people and had a patch landed.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Just for future reference bug 640463 was filed for the issue with OSX 10.5.8
You need to log in before you can comment on or make changes to this bug.