Add a WindowProxyHolder type and generate binding code that takes or returns it whenever
the WebIDL refers to the WindowProxy type. This patch just makes the WindowProxyHolder
hold a strong reference to a nsPIDOMWindowOuter.
Differential Revision: https://phabricator.services.mozilla.com/D12650
Add a WindowProxyHolder type and generate binding code that takes or returns it whenever
the WebIDL refers to the WindowProxy type. This patch just makes the WindowProxyHolder
hold a strong reference to a nsPIDOMWindowOuter.
Differential Revision: https://phabricator.services.mozilla.com/D12650
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
This patch creates a pluginProblem UA Widget and constructs it (instead of the XBL pluginProblem binding) when UA Widget is enabled.
Tests in browser/base/content/test/plugins/ are duplicated so that we could test both versions.
Depends on D11702
Differential Revision: https://phabricator.services.mozilla.com/D11703
This patch creates a pluginProblem UA Widget and constructs it (instead of the XBL pluginProblem binding) when UA Widget is enabled.
Tests in browser/base/content/test/plugins/ are duplicated so that we could test both versions.
Depends on D11702
Differential Revision: https://phabricator.services.mozilla.com/D11703
MIME type should be trimmed of parameters whenever it is retreived
from the tag it relates to, otherwise other checks may fail.
Differential Revision: https://phabricator.services.mozilla.com/D10803
MIME type should be trimmed of parameters whenever it is retreived
from the tag it relates to, otherwise other checks may fail.
Differential Revision: https://phabricator.services.mozilla.com/D10803
At the moment, a tag that has document type capabilities will try to
load tag content with invalid MIME types as a document. This patch
will cause the load to fail silently instead.
This will cause failures in certain WPTs that expect plugins to be
present to fill in MIME type requirements, which we currently don't
have available on CI. These WPTs have been disabled for the moment.
MozReview-Commit-ID: 9JGR4LClE5x
Differential Revision: https://phabricator.services.mozilla.com/D2542
At the moment, a tag that has document type capabilities will try to
load tag content with invalid MIME types as a document. This patch
will cause the load to fail silently instead.
This will cause failures in certain WPTs that expect plugins to be
present to fill in MIME type requirements, which we currently don't
have available on CI. These WPTs have been disabled for the moment.
MozReview-Commit-ID: 9JGR4LClE5x
Differential Revision: https://phabricator.services.mozilla.com/D2542
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
As part of applet/java plugin removal in bug 1279218, classid checking
was removed, as it was not obvious that this was used anywhere other
than java plugins. The classid is still a valid attribute on object
tags (and is sometimes used on tags for flash embedding). We want
to use a fallback strategy when we find objects with classid
attributes, as we don't support them, meaning we need to revert our
prior removal of the check.
MozReview-Commit-ID: BKQ34HGTkvt
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
