Closed
Bug 509046
Opened 15 years ago
Closed 6 years ago
Gtk embedding code locks up when a modal window is created, and doesn't handle chrome windows correctly
Categories
(Core Graveyard :: Embedding: GTK Widget, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: cwiiis, Unassigned)
Details
Attachments
(1 file)
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.2) Gecko/20090803 Fedora/3.5.2-2.fc11 Firefox/3.5.2
Build Identifier:
If you disable the nsIPromptService for gtkmozembed and you cause a modal window to be created, the process will lock up and have to be killed.
Further to this, chrome windows aren't handled correctly (window item type is always set as content, regardless of the chromeflags sent to the WindowCreator). If you fix the lock-up, you will then notice that all dialogs appear as empty with non-working OK/Cancel buttons (for the most-part).
I encountered these bugs while writing the headless backend and was guided through fixing them on Mozilla IRC - attached is a patch that back-ports these fixes to the gtk backend.
Note that ABI is preserved, but a new API call is added that is required if the user wants chrome dialogs to work correctly.
Reproducible: Always
Steps to Reproduce:
Reproducing without disabling the PromptService is hard, but there's a further bug that causes components to be de-registered it seems, so users of Epiphany (the Gnome web browser) would occasionally encounter this.
Although the first bug should be fixed, tracking that down is much harder (as it's intermittent), so this patch should at least stop the process from locking up and allow continuation and safe shut-down (possibly).
If you disable the the PromptService in the gtk embedding code though, just go to the url 'javascript:alert("Hello")'.
Actual Results:
It locks the embedding process (note, it hasn't locked, it just stops responding to input).
Expected Results:
I'd expect the above to launch a window with the text 'Hello', etc., as you'd expect, without locking up.
It locks up because EmbedWindow::ShowModal calls 'gtk_main', which then proceeds to sit there and do nothing. The attached patch replaces this part by spinning the mozilla mainloop instead, similar to xulrunner.
Reporter | ||
Comment 1•15 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Product: Core → Core Graveyard
Comment 2•6 years ago
|
||
Embedding: GTK Widget isn't a thing, closing.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•