Closed
Bug 408681
Opened 17 years ago
Closed 6 years ago
DOMPopupBlocked listener for gtkmozembed
Categories
(Core Graveyard :: Embedding: GTK Widget, enhancement)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: romaxa, Assigned: romaxa)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
DOMPopupBlocked signal for gtkmozembed signals interface
Updated•17 years ago
|
Attachment #293516 -
Flags: review?(mpgritti)
Updated•17 years ago
|
Assignee: nobody → romaxa
Comment 1•17 years ago
|
||
Passing the host through the signal seem unnecessary, since it can be derived from the URI. The signal used in epiphany expose more of the nsIDOMPopupBlockedEvent properties: void (* popup_blocked) (EphyEmbed *embed, const char *address, const char *target, const char *features); Looks pretty good to me, but I have a couple of doubts about it: 1 Do we need to expose requestingWindow? I can't think of cases where an embedding application would need to know which child window requested the popup but... 2 Should we encapsulate the popup properties in a GtkMozPopup object to be able to extend them in the future?
Updated•12 years ago
|
Product: Core → Core Graveyard
Comment 2•6 years ago
|
||
Embedding: GTK Widget isn't a thing, closing.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•