Closed Bug 1122697 Opened 11 years ago Closed 11 years ago

[Linux Only] When opening a bookmark folder, no tabs are opened when the opening multiple tabs dialog warning is dismissed

Categories

(SeaMonkey :: Bookmarks & History, defect)

SeaMonkey 2.32 Branch
x86
Linux
defect
Not set
normal

Tracking

(seamonkey2.32 fixed, seamonkey2.33 fixed, seamonkey2.34 fixed, seamonkey2.35 fixed)

RESOLVED FIXED
seamonkey2.35
Tracking Status
seamonkey2.32 --- fixed
seamonkey2.33 --- fixed
seamonkey2.34 --- fixed
seamonkey2.35 --- fixed

People

(Reporter: u347682, Assigned: philip.chee)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 Build ID: 20150112202541 Steps to reproduce: User agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 Build identifier: 20150112202541 Create a bookmarks folder with more than browser.tabs.maxOpenBeforeWarn bookmarks in it. Right-click on folder --> "Open All in Tabs" or middle-click on folder. Actual results: "Confirm open" dialog appears ("You are about to open ... tabs. ..."). Press "Open tabs" button. --> Nothing happens. Repeat and uncheck "Warn me..." checkbox. Click "Open tabs" button. --> Nothing happens. Repeat. --> Tabs will be opened because the dialog has been disabled. Tried a fresh profile, but it's still the same. Expected results: When clicking the "Open tabs" button in the warning dialog, all bookmarks in the folder should be opened in tabs.
Try restarting SeaMonkey in safe mode. Go: Help -> Restart with Add-ons Disabled.
WFM (Windows XP). > fresh profile No extensions installed? If that's the case, disable all your Plugins & test again.
Looks like a Linux only problem. It is OK on Windows (tested with a virtual Windows XP). But it does neither work with SeaMonkey 32-bit on Debian Wheezy, nor with the "unofficial" SeaMonkey 64-bit on Jessie. When you hit "Open tabs" the dialog just closes, but no tabs of the bookmarks folder are opened. I deleted the complete ".mozilla" directory (profile and all add-ons). Additionally I tried "Help -> Restart with Add-ons Disabled", but this does not change anything.
OK, some more info, although I really do not understand what is going on here: On Linux, when I press "Open tabs" the error console will show >> TypeError: focusManager.activeWindow is null >> resource://gre/modules/PlacesUIUtils.jsm in line 610 . So I put breakpoints in PlacesUIUtils.jsm on line 610 and 772 (to check the reallyOpen and buttonPressed vars). But when I hit the breakpoints, reallyOpen *is* true, buttonPressed *is* 0, and focusManager.activeWindow *is not* null. So when I continue, all the tabs in the folder *do* open. After removing the breakpoints, it stops working again. Is this some sort of race condition?
> _getTopBrowserWin: function PUIU__getTopBrowserWin() { > return focusManager.activeWindow.gPrivate || > Services.wm.getMostRecentWindow("navigator:browser"); > }, Possible wallpaper fix: - return focusManager.activeWindow.gPrivate || + return focusManager.activeWindow && focusManager.activeWindow.gPrivate || NEEDINFO->Neil
Flags: needinfo?(neil)
(In reply to Philip Chee from comment #5) > > _getTopBrowserWin: function PUIU__getTopBrowserWin() { > > return focusManager.activeWindow.gPrivate || > > Services.wm.getMostRecentWindow("navigator:browser"); > > }, > Possible wallpaper fix: > - return focusManager.activeWindow.gPrivate || > + return focusManager.activeWindow && focusManager.activeWindow.gPrivate || If focusManager.activeWindow is "broken" we should fix _getCurrentActiveWin and make _getTopBrowserWin use that.
Flags: needinfo?(neil)
(In reply to neil@parkwaycc.co.uk from comment #6) > If focusManager.activeWindow is "broken" we should fix _getCurrentActiveWin > and make _getTopBrowserWin use that. I'm drawing a blank on your "fix getCurrentActiveWin() and make _getTopBrowserWin use that". How about a suggestion?
(In reply to Philip Chee from comment #7) > (In reply to comment #6) > > If focusManager.activeWindow is "broken" we should fix _getCurrentActiveWin > > and make _getTopBrowserWin use that. > I'm drawing a blank on your "fix getCurrentActiveWin() and make > _getTopBrowserWin use that". How about a suggestion? Sorry, I meant to say we should try getMostRecentWindow(null) either instead of or as well as focusManager.activeWindow.
(In reply to neil@parkwaycc.co.uk from comment #8) > Sorry, I meant to say we should try getMostRecentWindow(null) either instead > of or as well as focusManager.activeWindow. Since this bug manifests itself only on Linux I'm going for "as well as" While investigating _getCurrentActiveWin() I noticed a bug in openNodeIn() which has been there since we converted history to places. > - this.openContainerNodeInTabs(aNode, aWhere); > + this.openContainerNodeInTabs(aNode, null, aWhere);
Assignee: nobody → philip.chee
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8554737 - Flags: review?(neil)
(In reply to Philip Chee from comment #9) > While investigating _getCurrentActiveWin() I noticed a bug in openNodeIn() > which has been there since we converted history to places. > > - this.openContainerNodeInTabs(aNode, aWhere); > > + this.openContainerNodeInTabs(aNode, null, aWhere); OK but that's not on beta right?
Comment on attachment 8554737 [details] [diff] [review] Patch v1.0 Possible fix. Looks like we never actually call openNodeIn for a container node, so the problem never arises...
Attachment #8554737 - Flags: review?(neil) → review+
Component: Tabbed Browser → Bookmarks & History
Summary: Warning dialog when opening many tabs is broken. → [Linux Only] When opening a bookmark folder, no tabs are opened when the opening multiple tabs dialog warning is dismissed
Comment on attachment 8554737 [details] [diff] [review] Patch v1.0 Possible fix. [Approval Request Comment] Regression caused by (bug #): N/A User impact if declined: On Linux unable to open a bookmark folder into tabs after dismissing the multiple tabs dialog warning. Testing completed (on m-c, etc.): Tested on comm-central. Risk to taking this patch (and alternatives if risky): low to none. If this doesn't work users aren't any worse off. String changes made by this patch: None.
Attachment #8554737 - Flags: approval-comm-release?
Attachment #8554737 - Flags: approval-comm-beta?
Attachment #8554737 - Flags: approval-comm-aurora?
Attachment #8554737 - Flags: approval-comm-release?
Attachment #8554737 - Flags: approval-comm-release+
Attachment #8554737 - Flags: approval-comm-beta?
Attachment #8554737 - Flags: approval-comm-beta+
Attachment #8554737 - Flags: approval-comm-aurora?
Attachment #8554737 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: