196052 - Ensure (targetted) link clicks, window opens can be controlled from embedding

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, defect)

Description

[Adam Lock]

A frequent request of embedders is to be handle clicks on the web page and to do
their own thing in response. That might include:

1. Handling URLs with particular schemes, e.g. foo:someLink
2. Trapping all link clicks
3. Trapping window.open and targetted links
4. Trapping calls that change the current URL, e.g. via metarefresh or
window.location.href

Currently, these are almost all covered by nsIURIContentListener and
nsIWindowCreator. In theory, the embedder can register their own content
listener they can decide whether to handle certain content, block it or hand it
off for default processing. By implementing their own window creator service,
they can control how new windows are created.

This meta bug is to cover any known gaps which includes:

1. URI content listener is not notified when redirects occur (bug 187612)
2. URI content listener is not notified when JS changes the current URL (no bug)
3. Targetted links are badly handled (bug 195992)
4. Embedder has no way to stop a new window being created (bug 195992)

Point 2 is that if Javascript decides to open a new window or change the current
location, the URI content listener is not informed because the URL change is not
treated as a link click.

Point 3 is that targetted links are handled by the URI content listener of the
newly created window. If the embedder doesn't want to create a chrome window to
know what the URL was, it has no way of stopping them at present except by
implementing a faulty nsIWindowCreator service that returns the existing chrome
window to short circuit Gecko into calling the existing URI content listener.

Comment 1

[Juan José Mata]

Cc'ing Dan as a result of discussion at our API review meeting today.

Comment 2

[Adam Lock]

*** Bug 187838 has been marked as a duplicate of this bug. ***

Comment 3

[Chris]

Attachment: Test case showing blocking bug (Mozilla 1.0 - Mozilla 1.3+) of parent frame accidentally substitued for subframe in BeforeNavigate2 event

Comment 4

[Benjamin Smedberg]

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.