I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
This adds the elements `formaction`, `data`, `ping`, `poster`.
We can't really add a test for the `<object data>`, since we never
allow `<object>` elements in the first place and we don't allow
settings exceptions for temporarily allowed elements.
Same for `poster` elements, since it's only used in media elements
and those are either all allowed or none.
Differential Revision: https://phabricator.services.mozilla.com/D78638
This adds the elements `formaction`, `data`, `ping`, `poster`.
We can't really add a test for the `<object data>`, since we never
allow `<object>` elements in the first place and we don't allow
settings exceptions for temporarily allowed elements.
Same for `poster` elements, since it's only used in media elements
and those are either all allowed or none.
Differential Revision: https://phabricator.services.mozilla.com/D78638
This refactoring achieves a few things:
1. Removing the duplication between the different check_use_counter_xxx
functions.
2. Increasing the number of repetitions that
BrowserTestUtils.waitForCondition uses so that we have intermittently
failures resulting from it reaching its maximum repetitions.
3. Checking all telemetry histograms from the one document at once,
rather than re-loading the document for each histogram checked.
(This saves a lot of time, and was the cause of macOS timeouts after
the -moz-appearance use counter checks were added.)
4. A change to use a CSS property use counter as a sentinel to determine
whether telemetry has been reported yet, rather than the number of
documents destroyed, since the browser might be loading various other
documents in the background that can cause us to advance the test
before telemetry has been reported.
Differential Revision: https://phabricator.services.mozilla.com/D78416
The lack of specificity for script intro type has lead the debugger to need
to make use of 'source.introductionType' and 'source.element' in order to
determine whether a given script was injected, or inline or fetched, which
is entirely unnecessary of the loader itself clearly tells us what type
of script we are working with. It also allows us to cleanly handle the case
of XUL, which previously was "scriptElement" but has no ".element" passed
in, so we were unable to know whether a given source was inline or not.
Differential Revision: https://phabricator.services.mozilla.com/D78435
