Closed Bug 598159 Opened 14 years ago Closed 14 years ago

crash in TabCandy with private browsing mode

Categories

(Firefox Graveyard :: Panorama, defect, P2)

x86_64
Linux

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sepulci, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre in console: (firefox-bin:10884): Gtk-CRITICAL **: gtk_clipboard_set_with_data: assertion `targets != NULL' failed NOTE: child process received `Goodbye', closing down Reproducible: Couldn't Reproduce Steps to Reproduce: 1. open private window 2. open some tabs 3. open TabCandy 4. close main (single) group (private mode) 5. put and drag mouse (to create new group)
I was able to reproduce this on Mac, latest nightly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I vaguely remember filing a bug similar to this, though. The application closes or crashes. There's no crash ID associated with this.
blocking2.0: --- → ?
Whiteboard: dupeme
Perhaps it was a clean shutdown without warning. But the null-pinter exception in console suggests otherwise.
Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre I can reproduce on Windows XP but I need to repeat step 5 several times. WinDBG attached does not catch an exception, looks like firefox.exe exits cleanly without warning. bug 597188?
Just to be clear, "security mode" refers to private browsing?
Priority: -- → P2
(In reply to comment #5) > Just to be clear, "security mode" refers to private browsing? Yes. I use Russian localization and could be mistaken in terms of.
Is this a dupe? Do we know the cause?
blocking2.0: ? → final+
Summary: crash in TabCandy with security mode → crash in TabCandy with private browsing mode
(In reply to comment #7) > Is this a dupe? Do we know the cause? No, in fact we don't even have a stack for the crash, and we certainly don't have STRs. Based on this, I'd like to ask for the blocking decision to be revisited.
blocking2.0: final+ → ?
Juan, I'm moving this to UNCONFIRMED, which conflicts with your comment 1; can you please change it back to NEW if you can still confirm it? And/or can someone put a URL to the stack in the bug?
Status: NEW → UNCONFIRMED
blocking2.0: ? → ---
Ever confirmed: false
I can reproduce the problem with the steps from comment #0 (the error in the console isn't exactly the same), but what seems to be happening is that closing a group closes the application. It might be a dupe of 597188
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 598154
bugspam (moving b9 to b10)
Blocks: 608028
bugspam (removing b9)
No longer blocks: 598154
Juan, Dmitry, are we still seeing this? I just tried to follow the STR, and the window closes if I close the "undo close group" button, as is the spec, but it doesn't crash.
Severity: minor → major
Keywords: qawanted
Whiteboard: dupeme → [dupeme][crash][WFM?]
I think this was in fact a duplicate of bug 597188. Closing the "Undo Close Group" button closes the application; it does not crash it. I also don't get the assertion mentioned in comment #0. I think this is a WFM.
Thanks Juan.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
Whiteboard: [dupeme][crash][WFM?]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.