Trying to do a positive check on nested URIs apparently doesn't work,
but the handling could be simplified to just check for non-null mURI
instead - this also fixes plugin loading (which broke with the previous
check).
If a website would nor supply a URI for object loading code, the browser
would crash on a null deref.
This reintroduces the nestedURI check to make sure we have a valid URI.
Youtube's usage patterns have changed regarding video embeds, so we can
remove special handling for the enablejsapi flag.
Applies YouTube embed URL replacement to the path component only.
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a
loading principal currently retrieve it from the context node.
Since no current callers require the principal to be the loading
principal, and some already expect it to be the triggering principal
(which there's currently no other way to retrieve), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
This removes a lot of the plumbing for having the platform embed itself
through IPC which was required for B2G running the browser as both
shell and browser application.
Adds --disable-npapi as an additional build option. The default is still to build in NPAPI compatibility, but with this flag, it's finally possible to build without pulling in GTK2 on systems that don't have the package.
This essentially ifdefs everything associated with NPAPI, following various Mozilla removal bugs.
Ref: BZ 1682030, BZ 1251202, BZ 1217665, BZ 1687239
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
Favor fallback content in that case (if present). Fallback is always
considered "good" in this case so may end up doing nothing which is what
we'd want for corner cases that hammer this routine with no content.
If a page uses or removes many <object> elements which are not actually plugins, loading the page goes to a crawl because UXP recalculates the plugin UI every time.
Only dispatch a PluginRemoved event for actual plugins.
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
Moonchild
athenian200
Brian Smith
wolfbeast
win7-7
adeshkp
wolfbeast
Matt A. Tobin