Note: There are a few cases of duplicates in user autocompletion which are being worked on.

SM 2.8 Mac - SM Not Returned to Open from Minimize to Dock

RESOLVED FIXED in seamonkey2.11

Status

SeaMonkey
Tabbed Browser
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Rufus, Assigned: stefanh)

Tracking

({regression})

Trunk
seamonkey2.11
x86
Mac OS X
regression
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.8 wontfix, seamonkey2.9 fixed, seamonkey2.10 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8
Build ID: 20120312221231

Steps to reproduce:

I Minimized the open SM Browser window into the Dock by double clicking on the SM Taskbar, then with SM Minimized attempted to open either of an html file on my Desktop from the Finder by double-clicking and/or clicking a link from an e-mail.


Actual results:

SM does not come forward from the Dock; i.e. - SM remains minimized even though the file or link *does* open in a new SM tab per my Preference setting.  User has to click the Minimized SM icon in the Dock to restore SM to Open.  Same behavior occurs if user invokes command+M to Minimize.


Expected results:

If user opens a link or html file using Safari when minimized to the Dock, Safari returns to Open from the Dock and the new page or file is displayed automatically.  This is default OS X interface behavior, and I have also verified that this behavior is/was working properly in SM 2.7.2; broken in SM 2.8.
(Reporter)

Comment 1

5 years ago
Noticed in addition today that not only does the above occur, but that when SM is already in the Open state and a link is clicked in another Space, that does not bring the Space containing SM to front - i.e.; if I click a link in an e-mail in Space 1 and SM is open in Space 2, the OS does not switch to Space 2 even though the link is opened in a new tab in SM per my preference setting.

Again - this was working in SM 2.7.2; broken in SM 2.8.
(Assignee)

Comment 2

5 years ago
Does this happen with Lion or snow Leaopard or does it happen with both OS versions?
(Assignee)

Comment 3

5 years ago
I can reproduce this on 2.8 and trunk (I'm on Lion). I just checked 2.7.2, and it works there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: SeaMonkey 2.8 Branch → Trunk
(Assignee)

Comment 4

5 years ago
This is a bit tricky to test when you have multiple apps with the same version installed, but I found out that I could test by right-clicking on a file and then choose the "Other..." option (navigating to the app).

This regressed between 2011-11-30 and 2011-12-02 and backing out the patch in bug 703522 fixes the issue for me.
Blocks: 703522
(Assignee)

Updated

5 years ago
Component: OS Integration → Tabbed Browser
QA Contact: os-integration → tabbed-browser

Comment 5

5 years ago
The old tab switching code looked for something to focus, and because there wasn't anything yet, it went and focused the content area.
But the new code focuses the browser element instead, which works better when switching back to a document that uses frames, but also doesn't invoke the focus-raises-window effect.
Now, this doesn't normally matter, because most of our new tab callers focus the content area anyway, but obviously there exists one that does not...
(Reporter)

Comment 6

5 years ago
(In reply to Stefan [:stefanh] from comment #2)
> Does this happen with Lion or snow Leaopard or does it happen with both OS
> versions?

Both Sno Lep and Lion.
(Assignee)

Updated

5 years ago
tracking-seamonkey2.10: --- → ?
tracking-seamonkey2.11: --- → ?
(Assignee)

Comment 7

5 years ago
Created attachment 611279 [details] [diff] [review]
Bring up the window if browser.tabs.loadDivertedInBackground is false

OK, this fixes the issue. If the pref is set to true, we don't bring up the window - that's probably correct (matches firefox).
Assignee: nobody → stefanh
Status: NEW → ASSIGNED
Attachment #611279 - Flags: review?(mnyromyr)

Comment 8

5 years ago
Comment on attachment 611279 [details] [diff] [review]
Bring up the window if browser.tabs.loadDivertedInBackground is false

>-        return gBrowser.getBrowserForTab(newTab).contentWindow;
>+        var contentWin = gBrowser.getBrowserForTab(newTab).contentWindow;
>+          if (!bgLoad)
>+            contentWin.focus();
Over indented?
(Assignee)

Comment 9

5 years ago
(In reply to Philip Chee from comment #8)
> >+        var contentWin = gBrowser.getBrowserForTab(newTab).contentWindow;
> >+          if (!bgLoad)
> >+            contentWin.focus();
> Over indented?

Ah, yes. I'll fix that on check-in.

Comment 10

5 years ago
I just tried the patch on Windows, and it seems to fix bug 736611 as well :-)
(Assignee)

Comment 11

5 years ago
Created attachment 611497 [details] [diff] [review]
Better indented

This doesn't seem to be mac-specific (comment #10), so maybe neil can have a look at the patch.
Attachment #611279 - Attachment is obsolete: true
Attachment #611279 - Flags: review?(mnyromyr)
Attachment #611497 - Flags: review?(neil)

Updated

5 years ago
Blocks: 736611

Updated

5 years ago
Attachment #611497 - Flags: review?(neil) → review+

Comment 12

5 years ago
This also affects 2.8 and beta...

Comment 13

5 years ago
Comment on attachment 611497 [details] [diff] [review]
Better indented

> This also affects 2.8 and beta...
We are not touching 2.8, only Aurora and Beta.

[Approval Request Comment]
Regression caused by (bug #): bug 703522.
User impact if declined: additional user step needed to raise the SeaMonkey window when external links are opened in a minimized SeaMonkey.
Testing completed (on m-c, etc.): Tested on Lion and Windows7.
Risk to taking this patch (and alternatives if risky): Minimal, this is a regression fix.
String changes made by this patch: None.
Attachment #611497 - Flags: approval-comm-beta?
(In reply to H. Hofer from comment #10)
> I just tried the patch on Windows, and it seems to fix bug 736611 as well :-)

If that is the case, mark it as a duplicate of this one.

(In reply to Philip Chee from comment #13)
> > This also affects 2.8 and beta...
> We are not touching 2.8, only Aurora and Beta.

Then why only request Beta approval? Do you think there is a risk involved for Aurora, or anything else objecting?

Comment 15

5 years ago
Comment on attachment 611497 [details] [diff] [review]
Better indented

Sorry, mis-fingered.
Attachment #611497 - Flags: approval-comm-aurora?
(Assignee)

Comment 16

5 years ago
http://hg.mozilla.org/comm-central/rev/b3f800023045
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.11

Updated

5 years ago
Attachment #611497 - Flags: approval-comm-beta?
Attachment #611497 - Flags: approval-comm-beta+
Attachment #611497 - Flags: approval-comm-aurora?
Attachment #611497 - Flags: approval-comm-aurora+
(Assignee)

Comment 17

5 years ago
I'll land on aurora/beta tomorrow or later on in the weekend.

Updated

5 years ago
Duplicate of this bug: 736611

Comment 19

5 years ago
Target Milestone Seamonkey 2.11

Isn't an earlier integration possible for 4 lines of code?
Till 2.11 it will take about 4 months and that's the most annoying bug I've ever had since Netscape 1.
(In reply to Trevor from comment #19)
> Target Milestone Seamonkey 2.11

Target Milestone equals the version of trunk at the time of the bug fix.

> Isn't an earlier integration possible for 4 lines of code?

The patch has already been approved for Aurora (to-be 2.10) and Beta (to-be 2.9), i.e. it'll be fixed for 2.9 for sure, probably our next beta 2.9b3 even.
status-seamonkey2.10: --- → affected
status-seamonkey2.8: --- → wontfix
status-seamonkey2.9: --- → affected

Comment 21

5 years ago
Good news :-)
Thanks for this information, Jens.
(Assignee)

Comment 22

5 years ago
Landed on aurora and beta:
http://hg.mozilla.org/releases/comm-aurora/rev/b7d96060bc37
http://hg.mozilla.org/releases/comm-beta/rev/81b871cdd9f8
status-seamonkey2.10: affected → fixed
status-seamonkey2.9: affected → fixed
tracking-seamonkey2.10: ? → ---
tracking-seamonkey2.11: ? → ---
You need to log in before you can comment on or make changes to this bug.