This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
This patch adds a new field to the `plugin-crashed` event that holds the list
of additional minidumps associated with a crash report. The test
infrastructure is modified to use it which also fixes a race when processing
the .extra file. The reftest machinery has also been modified to take the new
field into account.
Differential Revision: https://phabricator.services.mozilla.com/D54107
Finally, let's move the actual IO away from the main thread.
This means there are now 3 ways of looking for plugins:
1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable
on the main thread.
2. loading plugins from LoadPlugins. This will:
a) first check prefs and report the flash plugin based on that information,
if the prefs indicate it exists (using the callback provided by
nsPluginHost).
b) then hopefully dispatch to a background thread, where it will read
pluginreg.dat, scan the appropriate folders on disk, and see if
anything changed. Once done, it sets mFinishedFinding to true and
re-dispatches itself to the main thread.
c) then on the main thread, it reports any changes to nsPluginHost.
3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main
thread.
Note: if ReloadPlugins is called, we intiially do (1), but if we find
changes, we clear out the set of known plugins and then run LoadPlugins
again (meaning we go through 2 (or 3 if 2(b) fails)). This is how
reloading plugins worked prior to my changes and I've attempted not to
change it.
In order for this to work, there are some other changes in this commit:
- the sandbox prefs are being read "early" and cached for flash vs
"everything else". We can't access prefs on non-main threads without
using StaticPrefs, which doesn't seem worth it here.
- some of the plugin tag classes are moved to threadsafe refcounting.
This is a bit unfortunate, but because they're instantiated on a non-
mainthread, and then later used on the main thread, despite the
fact that the architecture means nothing tries to touch them from
more than one thread at once, without threadsafe refcounting we hit
asserts in debug mode if we add references to them back on the main thread.
- we add shutdown blocking for pluginfinding. We don't really want to
be halfway through finding plugins and then trying to shut them down,
or re-instantiating plugins after they've been unloaded.
- we keep a reference to the "pending" pluginfinder instance while
doing lookups away from the main thread (ie (2)), to avoid re-entrancy or
trying to write to pluginreg while we're reading it somewhere else,
etc. If there's an attempt to do more plugin finding while this is
ongoing, we flip mDoReloadOnceFindingFinished and do a reload once
our initial lookups are complete.
Depends on D48331
Differential Revision: https://phabricator.services.mozilla.com/D48332
This moves plugin finding logic into a separate class (PluginFinder).
PluginFinder is a runnable. After this commit, there are two ways in which it
can be used:
1. to actually find and load plugins.
2. to check if there have been any changes to plugins.
Although it is a runnable, at this point we still invoke its Run method on the
main thread, so all that's happening is we're separating the "look for plugins
on disk" bits out from everything else.
The goal is to be able to run the IO-intensive FindPlugins (including reading
and writing pluginreg) away from the main thread.
Depends on D48330
Differential Revision: https://phabricator.services.mozilla.com/D48331
Remove:
- a list of allowed mimetypes; we only support flash anyway.
- writing to disk when a plugin's enabled state changes; the plugin's enabled
state is not kept on disk so there's no point.
- tracking which plugins should load in the parent as no plugins should do so
if e10s is on.
Depends on D48329
Differential Revision: https://phabricator.services.mozilla.com/D48330
