window.close() crash in TestGtkEmbed

RESOLVED INCOMPLETE

Status

Core Graveyard
Embedding: GTK Widget
--
major
RESOLVED INCOMPLETE
16 years ago
4 years ago

People

(Reporter: Yanko Kaneti, Assigned: blizzard)

Tracking

({regression})

Trunk
x86
Linux
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [driver:blizzard], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
In Alex Barnes' word from galeon-devel

"If you go to http://www.tesco.com/register/ and click the "need some
help registering" link (need popups enabled), galeon displays the popup,
but then segfaults when you press the close button on the page."

it crashes in the visibilty callback after its been called zillion times
(Reporter)

Comment 1

16 years ago
here is another url that exhibits the behavior directly

http://www.it-vikar.no/web_nyheter_detalj.lasso?Nyhetsnr=n611id

both links in it are window.close()
Summary: TestGtkEmbed crash (mozilla 0.9.6) → window.close() crash in TestGtkEmbed (with 0.9.6)
(Reporter)

Comment 2

16 years ago
this bug is still absolutely reproducable for me with both 0.9.7 and recent cvs
Severity: normal → major
Summary: window.close() crash in TestGtkEmbed (with 0.9.6) → window.close() crash in TestGtkEmbed
(Assignee)

Comment 3

16 years ago
Sounds the same.  duping.

*** This bug has been marked as a duplicate of 121279 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 4

16 years ago
Ahh, it's not the same.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Assignee)

Comment 5

16 years ago
This only happens if it's the last window that's up.  I think it's because XPCOM
is being accessed after it has been shut down.  Looks like a window destruction
ordering issue.
(Assignee)

Updated

16 years ago
Blocks: 115520
Keywords: regression
(Assignee)

Updated

16 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 6

16 years ago
This is a reocurring problem.  There are two right ways to fix this:

o Require all callers to hold a reference to the embedding layer until _after_
all of the widgets have been destroyed.  Essentially require them to use
push_startup() and pop_startup().

o Require that any event that might cause the last window to be destroyed will
unwind its stack in such a way that it won't need anything from the XPCOM library.

I'm starting to think that the previous one is the proper solution.  I could put
code in the embedding library that would make it so that this would be tracked
and a warning would be spewed if XPCOM was shut down during the last widget
destruction.
Dan might have some ideas on this.
(Assignee)

Comment 8

16 years ago
I need some feedback.  I need to get this issue taken care of (fix the test case
or the issue) before I can feel comfortable seeing 0.9.8 go out the door.
(Assignee)

Updated

16 years ago
Whiteboard: [driver:blizzard]
(Assignee)

Comment 9

16 years ago
Created attachment 66905 [details] [diff] [review]
fix the test case

This fixes the test case.
(Assignee)

Comment 10

16 years ago
Taking this off the 0.9.8 radar since it's really a bug with the test case, not
in the product.
No longer blocks: 115520
Can we close this bug at this point? Fixed? obsolete? wontfix?
QA Contact: pavlov → gtk-widget
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
(Reporter)

Comment 12

4 years ago
Flash from the past. Closing. Sorry if it was waiting on me.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.