Closed Bug 521699 Opened 15 years ago Closed 15 years ago

When SM is running, double clicking on saved web page opens home page

Categories

(SeaMonkey :: Startup & Profiles, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.1a1

People

(Reporter: rbgray, Assigned: stefanh)

References

()

Details

(Keywords: fixed-seamonkey2.0.3)

Attachments

(1 file)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4) Gecko/20091007 SeaMonkey/2.0

Running the standard Litmus Save As test is producing strange results.

Steps to reproduce (https://litmus.mozilla.org/run_tests.cgi?test_run_id=7 Functionality Step 8):

1. Open http://www.google.com in a new window.

2. File > Save Page As  Google.html to the Desktop, Web Page, complete

3. Close the Google window and minimize the rest of SeaMonkey (cmd-h)

4. double click on the saved Google.html file

Expected results:

1. The first time I access the file, I get the Mac OS X quarantine warning:  "Google.html" is a web application downloaded from the Internet.  Are you sure you want to open it?  I click (Open)
2. Get the saved Google page

Actual results:

In my working profile, "default", the Litmus and this bugzilla windows re-display, with the quarantine dialogue on top.  When I answer Open, a blank window appears under the litmus & bugzilla windows.  Its source is just "<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><title></title></head><body></body></html>".  This despite the fact that the disk file and images folder appear to have been written correctly and all saves do open correctly in Safari.  SeaMonkey Open File seems to work correctly.

In the clean profile I was using for the smoketest, I was getting the saved google page, then my designated home page opening over it in a new window. When I repeated the test with www.bing.com, all I got was my homepage.
Flags: blocking-seamonkey2.0?
It looks as if there is no problem with the saved page, it opens fine in Safari and SM 1.1.18.  Google.com Save As'ed in 1.1.18 opens fine in that version, but also opens the homepage in 2.0rc1.  So this is really some sort of opening by double-click bug.  

Interestingly, when I switch from the clean profile I'm using to test this bug back to my working profile, the homepage comes up blank.  When I double click on a saved page, I get blank instead of my homepage or even the saved page.

Also, I no longer the the saved page opening with the home page, just the home page.

Renaming the bug from "File > Save Page As producing unpredictable results" to "Double clicking on saved web page opens home page".  Withdrawing blocking 2.0 request and taking importance to "normal" since there is a work-around of File > Open File (which works correctly.)
Severity: major → normal
Flags: blocking-seamonkey2.0?
Summary: File > Save Page As producing unpredictable results → Double clicking on saved web page opens home page
Assuming that "double-clicking" means "opening from an external program" (e.g. Finder or the desktop), I assume that startup URL handlers have something to do with this and moving it to the startup component.

As this is mac, I wonder if Mark or Karsten know anything about this.
Component: Download & File Handling → Startup & Profiles
QA Contact: download → profile-manager
iirc Firefox 3.5 also has this problem on Mac.
Actually, I don't think it is a startup problem per se, because I was doing this with a Litmus window open.   It seems more a new window thing.  In fact, I just Quit SM and started it by clicking on a helloworld.html file made with composer and the hello world page came up.  I then closed that window (SM still running, now with no windows) and clicked the helloworld.html file again.  This time I got my homepage.

What I meant to say in #1 was I no longer see the saved page opening with the home page, just the home page opens.

I wonder if Stefan knows of this...
Everything calling us from an external source basically goes through the startup code in some way (URL handlers or whatever).
bug 505298, bug 501115, bug 457572, bug 420334, bug 423254 seems instances of this on Firefox, all have been reported on Mac, so this might be a Mac-specific issue.
Two comments: 1. The same seems to happen with a saved e-mail. 2. If SeaMonkey is running and (instead of double-clicking on the saved file) one opens it via File menu > Open File, the file opens properly (not the home page).
The same problem occurs not only when double-clicking an html file on the Mac, but also when dragging and dropping it onto the SeaMonkey icon (either directly or on the dock) [see Bug 531562]. Indeed it looks like a Mac problem, but one that didn't exist in any previous 1.x version of SeaMonkey.
Blocks: 531562
mcsmurf and I have discussed this a bit. I first noted that Firefox handles local files differently, then mcsmurf pointed out that https://bugzilla.mozilla.org/attachment.cgi?id=358454 in bug 290057 added a -file arg handling which we seem to depend on. I need to test this a bit further, but it looks like it fixes this bug and all the dupes.
Assignee: nobody → stefanh
Attachment #417386 - Attachment is patch: true
Attachment #417386 - Attachment mime type: application/octet-stream → text/plain
Interestingly, on trunk opening a local file when SeaMonkey is *not* running seems broken (the patch fixes the case when SeaMonkey already is running, though)
Comment on attachment 417386 [details] [diff] [review]
Look for "file" args 

See https://bug290057.bugzilla.mozilla.org/attachment.cgi?id=358454 in bug 290057 for why we need this.
Attachment #417386 - Flags: superreview?(neil)
Attachment #417386 - Flags: review?(mnyromyr)
Status: NEW → ASSIGNED
Target Milestone: --- → seamonkey2.1a1
Comment on attachment 417386 [details] [diff] [review]
Look for "file" args 

Nit: please use the style of the existing -url flag (but without the _handledURI stuff of course).
Attachment #417386 - Flags: superreview?(neil) → superreview+
This doesn't work for me at all, using a SeaMonkey trunk debug build under 10.5. Regardless of whether SM is already running or not, all I get when trying to open/open with/doubleclick the html file in the Finder is this assertion:

WARNING: NS_ENSURE_TRUE(aCFURL) failed: file /Users/karsten/moz/src/trunk/mozilla/xpcom/io/nsLocalFileOSX.mm, line 1555
(In reply to comment #16)
> This doesn't work for me at all, using a SeaMonkey trunk debug build under
> 10.5. Regardless of whether SM is already running or not, all I get when trying
> to open/open with/doubleclick the html file in the Finder is this assertion:

Have you set SeaMonkeyDebug to the app to open the file?
Oh, wait - that shouldn't matter for 'open with'. Odd, the patch works flawless for me on trunk (10.5.8) when seamonkey is already running.
Blocks: 520610
Comment on attachment 417386 [details] [diff] [review]
Look for "file" args 

This does only(!) work for me on SeaMonkey 1.9.1 branch, but there it does work for both the "SM running" and the "SM not running" case. Thus this r+ is only valid for SM 2.0.x!
The trunk behaviour is broken for me even in Minefield, so this may be a PPC (me) vs. Intel (Stefan) issue.
Attachment #417386 - Flags: review?(mnyromyr) → review+
Depends on: 512129
Karsten, I don't see any reason for not taking the patch on trunk. The only thing it does is that it looks for the -file arg and If nsBrowserContentHandler.js can't find any flags/paths for ppc builds, I would say that the issue is to be found in toolkit/xre.
Comment on attachment 417386 [details] [diff] [review]
Look for "file" args 

I think we need this for 2.0.2. It's safe and it fixes a really annoying problem on mac.
Attachment #417386 - Flags: approval-seamonkey2.0.2?
Adjusting summary a bit - this only covers the "running" case.
No longer depends on: 512129
Summary: Double clicking on saved web page opens home page → When SM is running, double clicking on saved web page opens home page
Attachment #417386 - Flags: approval-seamonkey2.0.2? → approval-seamonkey2.0.2+
(In reply to comment #20)
> Karsten, I don't see any reason for not taking the patch on trunk. The only
> thing it does is that it looks for the -file arg and If
> nsBrowserContentHandler.js can't find any flags/paths for ppc builds, I would
> say that the issue is to be found in toolkit/xre.

Okay, fine by me.
Pushed with comment #15 addressed:
http://hg.mozilla.org/comm-central/rev/9ff7974b294d
http://hg.mozilla.org/releases/comm-1.9.1/rev/700e177cf42f
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
No longer blocks: 531562
Note: Even though comment #21 indicates that this is fixed in 2.0.2, this is not the case - it will instead be fixed in 2.0.3.
It's definitely not fixed in 2.0.2. And it's not confined to PPC. I have the same problem running 2.0.2 in OS X v10.4.11 on a MacBook Pro (Intel) and on a G5 DP 2.5 (PPC) .

There are other manifestations of this double-click-to-open problem in SeaMonkey 2.0.x. If the Appearance preferences are set to "When SeaMonkey starts up, open Mail & Newsgroups", double-clicking on an HTML file causes an already-launched SeaMonkey to open the main Mail & Newsgroups window. After changing the Appearance preference to "When SeaMonkey starts up, open Browser", double-clicking on an HTML file causes SeaMonkey to open a blank browser window, but it does not load the HTML file in question.

It's good to know this will be fixed in 2.0.3.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: