Closed
Bug 598159
Opened 14 years ago
Closed 14 years ago
crash in TabCandy with private browsing mode
Categories
(Firefox Graveyard :: Panorama, defect, P2)
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)
Comment 1•14 years ago
|
||
I was able to reproduce this on Mac, latest nightly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•14 years ago
|
||
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
Reporter | ||
Comment 3•14 years ago
|
||
Perhaps it was a clean shutdown without warning.
But the null-pinter exception in console suggests otherwise.
Comment 4•14 years ago
|
||
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?
Comment 5•14 years ago
|
||
Just to be clear, "security mode" refers to private browsing?
Priority: -- → P2
Reporter | ||
Comment 6•14 years ago
|
||
(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.
Comment 7•14 years ago
|
||
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
Comment 8•14 years ago
|
||
(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+ → ?
Comment 9•14 years ago
|
||
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
Comment 10•14 years ago
|
||
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
Comment 13•14 years ago
|
||
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.
Comment 14•14 years ago
|
||
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.
Comment 15•14 years ago
|
||
Thanks Juan.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•