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

RESOLVED FIXED in seamonkey2.1a1

Status

SeaMonkey
Startup & Profiles
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: rbgray, Assigned: stefanh)

Tracking

({fixed-seamonkey2.0.3})

Trunk
seamonkey2.1a1
x86
Mac OS X
fixed-seamonkey2.0.3

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

1.03 KB, patch
Karsten Düsterloh
: review+
neil@parkwaycc.co.uk
: superreview+
Karsten Düsterloh
: approval-seamonkey2.0.3+
Details | Diff | Splinter Review
(Reporter)

Description

8 years ago
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?
(Reporter)

Comment 1

8 years ago
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

Comment 2

8 years ago
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.
(Reporter)

Comment 4

8 years ago
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...

Comment 5

8 years ago
Everything calling us from an external source basically goes through the startup code in some way (URL handlers or whatever).

Updated

8 years ago
Duplicate of this bug: 523721

Comment 7

8 years ago
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.

Comment 8

8 years ago
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).

Comment 9

8 years ago
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.
(Assignee)

Updated

8 years ago
Blocks: 531562
(Assignee)

Updated

8 years ago
Duplicate of this bug: 532938
(Assignee)

Updated

8 years ago
Duplicate of this bug: 531539
(Assignee)

Comment 12

8 years ago
Created attachment 417386 [details] [diff] [review]
Look for "file" args 

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
(Assignee)

Updated

8 years ago
Attachment #417386 - Attachment is patch: true
Attachment #417386 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Comment 13

8 years ago
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)
(Assignee)

Comment 14

8 years ago
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)
(Assignee)

Updated

8 years ago
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+

Comment 16

8 years ago
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
(Assignee)

Comment 17

8 years ago
(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?
(Assignee)

Comment 18

8 years ago
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.
(Assignee)

Updated

8 years ago
Blocks: 520610

Comment 19

8 years ago
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+

Updated

8 years ago
Depends on: 512129
(Assignee)

Comment 20

8 years ago
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.
(Assignee)

Comment 21

8 years ago
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?
(Assignee)

Comment 22

8 years ago
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

Updated

8 years ago
Attachment #417386 - Flags: approval-seamonkey2.0.2? → approval-seamonkey2.0.2+

Comment 23

8 years ago
(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.
(Assignee)

Comment 24

8 years ago
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
Last Resolved: 8 years ago
Keywords: fixed-seamonkey2.0.2
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
No longer blocks: 531562
Duplicate of this bug: 531562

Updated

8 years ago
Duplicate of this bug: 539172
(Assignee)

Comment 27

8 years ago
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.

Comment 28

8 years ago
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.