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.
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.
Does this happen with Lion or snow Leaopard or does it happen with both OS versions?
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
Version: SeaMonkey 2.8 Branch → Trunk
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.
Component: OS Integration → Tabbed Browser
QA Contact: os-integration → tabbed-browser
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...
(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.
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 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?
(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.
I just tried the patch on Windows, and it seems to fix bug 736611 as well :-)
This doesn't seem to be mac-specific (comment #10), so maybe neil can have a look at the patch.
This also affects 2.8 and beta...
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.
(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 on attachment 611497 [details] [diff] [review] Better indented Sorry, mis-fingered.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.11
I'll land on aurora/beta tomorrow or later on in the weekend.
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.
Good news :-) Thanks for this information, Jens.
You need to log in before you can comment on or make changes to this bug.