Closed Bug 408681 Opened 17 years ago Closed 6 years ago

DOMPopupBlocked listener for gtkmozembed

Categories

(Core Graveyard :: Embedding: GTK Widget, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: romaxa, Assigned: romaxa)

References

Details

Attachments

(1 file)

Attached patch Patch (deleted) — Splinter Review
DOMPopupBlocked signal for gtkmozembed signals interface
Attachment #293516 - Flags: review?(mpgritti)
Assignee: nobody → romaxa
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?
Product: Core → Core Graveyard
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.

Attachment

General

Created:
Updated:
Size: