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)

x86
Linux
defect
Not set
normal

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.
Product: Core → Core Graveyard
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.

Attachment

General

Created:
Updated:
Size: