YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
Cmd-line params for the SharedPreferenceSerializer was
duplicated in ContentParent and
SocketProcessHost. Since we'll have a 3rd process (RDD)
using this same code, let's move the repsonsiblity for knowing how to add
these cmdline params into SharedPreferenceSerializer.
Depends on D26567
Differential Revision: https://phabricator.services.mozilla.com/D26568
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Check if the current parent element is an HTML template element and if it
is, append to the document fragment instead of it.
Differential Revision: https://phabricator.services.mozilla.com/D26768
--HG--
extra : moz-landing-system : lando
It seems that in some scenarios, the lifetime of the visual viewport
object exceeds the lifetime of the prescontext. In particular, the
prescontext produced by GetPresContext() can be torn down and a new one
installed. This can leave the visual viewport in a wedged state where it
has scheduled events to be dispatched, but they will never actually be
dispatched, and then subsequent events will not get scheduled. This
patch checks to see if the prescontext has changed, and if so, discards
the old events and reschedules new ones.
Differential Revision: https://phabricator.services.mozilla.com/D26578
--HG--
extra : moz-landing-system : lando
Distinguish broadcast trigger from startup trigger in Remote Settings Uptake events
Differential Revision: https://phabricator.services.mozilla.com/D25585
--HG--
extra : moz-landing-system : lando
- Watch for if a proxy shuts down during init and if so, shutdown the CDM parent
that is being initialized.
- Make ChromiumCDMParent only store a pointer to a ChromiumCDMProxy when it has
successfully initialized. This avoid the lopsided relationship where a if a
ChromiumCDMParent fails to initialize it may keep a pointer to a proxy, but
the proxy will never have a reference to that CDM parent.
Differential Revision: https://phabricator.services.mozilla.com/D26208
--HG--
extra : moz-landing-system : lando
This code is calling other code that expects to be on the main thread, and
having this on the main thread (now that the main thread is a serial event
target) makes it easier to reason about this and other main thread code. I.e.
this cannot be running during other main thread code.
Differential Revision: https://phabricator.services.mozilla.com/D26206
--HG--
extra : moz-landing-system : lando
This gives us greater flexibility in using the main thread member to run
promises.
The site where we obtain the main thread returns a serial event target, so we're
not doing much more work here, we're just keeping the serial event target
interface, rather than converting to an event target interface.
Differential Revision: https://phabricator.services.mozilla.com/D26205
--HG--
extra : moz-landing-system : lando
Also remove unneeded MOZ_COUNT_[CTOR|DTOR] macros. We already get similar
functionality from NS_INLINE_DECL_THREADSAFE_REFCOUNTING.
Differential Revision: https://phabricator.services.mozilla.com/D26204
--HG--
extra : moz-landing-system : lando
This commit adds a smart pointer class that verifies that no dangling
pointers remain after the pointee went out of scope. This verification is
opt-in and can be controlled both statically and dynamically by the pointee.
Differential Revision: https://phabricator.services.mozilla.com/D25200
--HG--
extra : moz-landing-system : lando
Warn instead of asserting since it's possible for decoders to give us 0 by 0
frames here.
Differential Revision: https://phabricator.services.mozilla.com/D26612
--HG--
extra : moz-landing-system : lando
EME key system constants are used with UTF-8 functions where ASCII functions would do
Differential Revision: https://phabricator.services.mozilla.com/D25730
--HG--
extra : moz-landing-system : lando
ImageEncoder::ExtractDataInternal takes a `const nsAString&` for its
options, but flattens it into a null-terminated `nsString` so callees
can take a `char16_t*`. But nearly all of those callees eventually wind
up calling ImageEncoder::GetInputStream, which just constructs an
`nsDependentString` from the passed character pointer.
There's no reason to do all this extra work. We can just pass the
original options reference all the way through the stack and avoid
needless conversions.
Differential Revision: https://phabricator.services.mozilla.com/D26353
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
mJavaDecoder is invalid after the decoder is shut down and should never
be used.
Differential Revision: https://phabricator.services.mozilla.com/D26438
--HG--
extra : moz-landing-system : lando
SaferMultDiv(time, audioScale, videoScale) could easily result in overflow
because all three args are roughly equal, and SaferMultDiv would always do the
multiplication first. The worst-case is then multiplying an int64_t to another
int64_t that have very similar values. Since we represent time here in
microseconds, this would overflow after only 50 minutes.
Differential Revision: https://phabricator.services.mozilla.com/D26494
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
If insertion string ends with ASCII whitespace and there is no following
content in the block, `HTMLEditRules::AdjustWhitespaces()` needs to insert
`<br>` element. It's called only by `HTMLEditRules::AfterEditInner()` and
that does only simple things with `WSRunObject`. Therefore, this moves the
code into `AfterEditInner()`.
For making it adjust the whitespaces, `HTMLEditRules::WillInsertText()` needs
to notify `AfterEditInner()` of dirty range with `mDocChangeRange`. Therefore,
this patch makes it set `mDocChangeRange` manually after inserting composition
string.
On the other hand, there is another bug. `WSRunObject` was designed to treat
only inserting text for `WSRunObject::InsertText()`. I.e., not designed to
treat replacing existing composition string with new string. Therefore,
`WSRunObject::InsertText()` adjusts whitespaces only around start of
composition string. Therefore, if composition string ends with an ASCII
whitespace, it's not replaced with NBSP and that causes:
- failing `WSRunObject::AdjustWhitespaces()` inserts `<br>` element at
`AfterEditInner()` of committing composition.
- then, next composition's first `WSRunObject::InsertText()` removes the
last whitespace due to not followed by `<br>` nor any other content.
Therefore, this patch makes `WSRunObject` takes 2 DOM points to be able to
treat replaced range.
In strictly speaking, the latter change require more changes and tests for
supporting replacement with any other methods. However, it's risky and out
of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D26423
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
HandleOutput() runs on Android binder thread pool and could be preempted
by RemoteDateDecoder task queue. That means ProcessOutput() could be scheduled
after ProcessShutdown() or ProcessFlush(). When that happens, aBuffer is no
long valid and should never be processed, and aSample can be
recycled immediately.
Also assert preconditions of buffers received from Java callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D26189
--HG--
extra : moz-landing-system : lando
roundTripTime can be zero once it has been non-zero this should help with intermitents in WPT and mochitests
Differential Revision: https://phabricator.services.mozilla.com/D25981
--HG--
extra : moz-landing-system : lando
nsFrameLoaderOwner::UpdateRemoteness will recreate the nsFrameLoader for a
piece of content. As part of this, it will unset the cached nsFrameLoader for
the content's nsSubdocumentFrame. However we need to run ShowViewer() for the
new nsFrameLoader as the frame has already been initialized. In addition,
dimensions and position on the new nsFrameLoader need to be set. Usually this
is done after a reflow, but there's no guarantee a reflow will happen after
a UpdateRemoteness operation.
Differential Revision: https://phabricator.services.mozilla.com/D25662
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
Summary:
Currently, `IMEStateManager::SetIMEState` sets hint to the following logic.
- If there is no submit button into form element, set `next`
- If there is submit button, set `search` or `go`
- If there isn't into form element, no hint.
But Chrome sets `next` hint when next focusable element is input that is text
control. So even if there is submit button into form element, we should set
`next` to hint when next focusable element is input that is text/number
control and is in form.
Also, If current focused element isn't in `<form>`, I don't still set hint.
`nsFocusManager::DetermineElementToMoveFocus` may set focus to cross-process
document. So `next` is set when in form and it isn't last element in form.
Reviewers: masayuki
Reviewed By: masayuki
Subscribers: JanH
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D12885
--HG--
extra : rebase_source : f9d297416c046d9b718d9ff925006c162d67f286
extra : histedit_source : d8d946deb81f1f961d002e32720eb9a40a91bf64
Summary: To make setting action hint simple, I would like to move it to static function.
Reviewers: masayuki
Reviewed By: masayuki
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D24832
--HG--
extra : rebase_source : 730451dd56d0d0d2b8208765cac979f54b9745b1
extra : histedit_source : 5775444e938ec3dfa01e8a7a624dea49b785b307
Actually, there is no public method to get next element/content by tabIndex or
TAB key. So I would like to use GetNextTabbableContent from IMEStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D12884
--HG--
extra : rebase_source : 48fa0bb3cd834e9458ad69be1a08f3f32afd1049
extra : histedit_source : 5ce46db9caf5e970e5ed31c0a9e30bd656242684
It's possible to overflow when we do the position calculation, we should only store the position which won't cause the integer overflow when adding it to start time.
Differential Revision: https://phabricator.services.mozilla.com/D25340
--HG--
extra : moz-landing-system : lando
This patch extracts two additional CompositorHitTestInfo flags from the
eDispatchToContent flag; eApzAwareListeners for elements that have
APZ-aware listeners, and eInactiveScrollframe for inactive scrollframe
or unlayerized scrollthumbs. The eDispatchToContent is then renamed to
eIrregularArea to reflect the fact that it is used for irregular-shaped
areas that require main-thread hit-testing.
Additionally, it is important to note that when using the non-WebRender
codepath, all three of these flags still end up gettings squashed into
the "dispatch to content" region on the EventRegions; when APZ
reconstructs a CompositorHitTestInfo it will turn anything in this
region back into an eIrregularArea. So this is a lossy round-trip
conversion for the non-WebRender case. However it should still result in
correct behaviour because the semantics of eIrregularArea result in APZ
relying on the main-thread to do hit-testing and so any APZ-aware
listeners and inactive scrollframes are also handled by the main-thread.
Differential Revision: https://phabricator.services.mozilla.com/D26440
--HG--
extra : moz-landing-system : lando
This permission checking should be handled by PermissionUI.jsm, to be able to apply custom heuristics
for denying the permission and also to be able to "post-prompt" after denying automatically.
Differential Revision: https://phabricator.services.mozilla.com/D25416
--HG--
extra : moz-landing-system : lando
nsIPresShell.h is widely included, so this avoids excessively long rebuilds
when MobileViewportManager.h is modified.
Differential Revision: https://phabricator.services.mozilla.com/D26245
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
This preserves the behavior of not having FontFace objects for @font-face rules
in display: none iframes.
Note, however that we may want to always track stylesheets to both not have this
limitation and to fix bug 1471231 & co. But that's a separate bug in any case.
The assertion that is failing ultimately in this bug is not really relevant
anymore, so remove it while at it.
Differential Revision: https://phabricator.services.mozilla.com/D26196
--HG--
extra : moz-landing-system : lando
This bug is happening because we resolve the child of the content generating the
first-line frame inheriting from the XBL marquee's anonymous content (which
isn't affected by the all:inherit rule and thus is non-floating).
Then we go through frame construction, and remove the <marquee> binding, which
makes the anonymous content go away, but don't restyle the children again.
The correct first-letter style without the binding is floating, but we don't
realize while constructing the frame tree.
We do realize of that afterwards though, when reparenting the styles, and
inherit from the right thing, and thus get the right floating style. But there's
nothing saving us now, since the first-letter frame is in-flow already.
The fix is clearing the style of children before removing the binding, the same
way we do before adding it.
FlushStyleBindings removes the current XBL binding. That shuffles the flattened
tree. We need to ensure the styles are gone on children before that to avoid
getting into a bad state.
AutoStyleElement already does that, just slightly too late if there's a
pre-existing binding, so moving it up a bit does the trick.
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
WindowGlobalChild.cpp was relying on several headers already included by other
files in its unified build translation unit, but the addition of the
RemoteWebProgressRequest in the next change bumps them into another translation
unit and breaks the build.
The missing `#include` and `using namespace` statements have been added,
allowing builds to succeed.
Differential Revision: https://phabricator.services.mozilla.com/D24937
--HG--
extra : moz-landing-system : lando
Due to adding a new CPP file in the next change, the unified build fails due to
files being shuffled around between translation units. This change fixes the
build.
Differential Revision: https://phabricator.services.mozilla.com/D24810
--HG--
extra : moz-landing-system : lando
The implementation of WebProgressChild.jsm filters all nsIWebProgress events
through an nsBrowserFilter. We need to do this in the TabChild as well, but
TabChild currently only handles onContentBlockingEvent, for which
nsBrowserFilter only calls the underlying listener.
We also unregister the progress listener much earlier in TabChild::Destroy as
this method causes OnStateChange event to be triggered later on, which we are
not interested in capturing.
Differential Revision: https://phabricator.services.mozilla.com/D24805
--HG--
extra : moz-landing-system : lando
There is no specified limit on the number of inputs or outputs, except that
the webidl parameter is unsigned long, but Gecko has an implementation-defined
limit.
Differential Revision: https://phabricator.services.mozilla.com/D25898
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsPICommandUpdater` is a scriptable interface, but nobody refers it from JS,
and it's implemented only by `nsCommandManager`. Therefore, we can get rid
of this interface.
Additionally, `nsCommandManager::Init()` is called only by `nsDocShell`, which
is the only instantiater of the class, and returns error only when given window
is nullptr. Therefore, we can make the constructor take the window instead.
Differential Revision: https://phabricator.services.mozilla.com/D25729
--HG--
extra : moz-landing-system : lando
`nsIControllerContext` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, it can be a builtinclass.
Additionally, it's `init()` returns always `NS_OK`, and always called with
`null` from JS, and always called with an instance from C++. So that its the
only implementation, `nsBaseCommandController` can have 2 constructors which
does what `Init()` currently does.
Differential Revision: https://phabricator.services.mozilla.com/D25728
--HG--
extra : moz-landing-system : lando
Currently TabParent is refcounted, but nsFrameLoader hold a weak pointer. The pointer
should be cleared out when the TabParent is destroyed, but that's a bit of a footgun
and it's not obvious that we always do this correctly.
Because TabParent holds a reference to a nsFrameLoader and the frame element (which
contains a nsFrameLoader), I think this means we need to cycle collect TabParent.
--HG--
extra : rebase_source : 06e04c2ba8ea81d996d2688a1b0064aa37f45bbc
PPluginInstance's __delete__ was ported from rpc to intr, and is the
only non-async IPDL deletion in the codebase. We should be able to
align this with the rest of the IPDL interfaces and remove the need
for specialized intr __delete__ handling.
Differential Revision: https://phabricator.services.mozilla.com/D25674
--HG--
extra : moz-landing-system : lando
Additional test needs to be disabled for widows10-aarch64 due to lack of plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D25889
--HG--
extra : moz-landing-system : lando
Moves most of the RTL handling from XULDocument into Document. Creates
a new static class that listens to the direction pref change and notifies
all the documents when it changes.
Differential Revision: https://phabricator.services.mozilla.com/D25887
--HG--
extra : moz-landing-system : lando
This stack is pretty clear that calling StopListeningForVisibilityEvents
(via ClearTransaction) is a no-go from the cycle collector. We need to instead
just do the minimum version of bug 1540378, just reset mTransaction and move on.
Differential Revision: https://phabricator.services.mozilla.com/D25804
--HG--
extra : moz-landing-system : lando
In Bug 1448408 ("Don't listen to visibility events"), I changed `U2FTokenManager::
ClearTransaction` to send aborts, to handle the new visibility states. However,
`WebAuthnTransactionParent::ActorDestroy` is called at the conclusion of IPC
shutdown, which calls `MaybeClearTransaction` in `U2FTokenManager`, which calls
ClearTransaction, which then tries to send an Abort, which is a state machine
failure since we just shut the IPC down.
This patch creates a new `AbortOngoingTransaction` method which is used
to send the aborts instead of shoehorning that into `ClearTransaction`, reverting
`ClearTransaction` back to the prior form, and instead changes `Register` and
`Sign` to call the new method.
Differential Revision: https://phabricator.services.mozilla.com/D25687
--HG--
extra : moz-landing-system : lando
`nsIControllerCommandTable` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, it's inherited only by nsControllerCommandTable. So, all users
in C++ can treat the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D25727
--HG--
extra : moz-landing-system : lando
`nsICommandManager` isn't implemented by JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, this patch makes all users in C++ use `nsCommandManager` which is
the only implementation of `nsICommandManager`. This avoids QI from
`nsICommandManager` to `nsPICommandUpdater`.
Differential Revision: https://phabricator.services.mozilla.com/D25726
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
`nsChildView::GetEditorView()` is called by `TextInputHandlerBase::GetWindowLevel()`
which is called when Cocoa requests window level of focused widget.
It currently gets widget including focused element (e.g., it may be in a XUL
`<panel>`) with `eQueryTextContent` event. However, it requires only the widget
(i.e., when a XUL `<panel>` has focused element, the widget for the panel).
Therefore, it does not require to flush the layout.
However, on macOS, `ContentEventHandler` always flushes layout even with
`eQueryContentState` which does not require any layout information. Whether
it requires flushing layout or not is considered with
`WidgetQueryContentEvent::mNeedsToFlushLayout` but this is set to false only
when `IMEContentObserver` notifies widget (and IME) of focus set. At this
time, only on macOS, IME caches the layout information, for example, the
character coordinates, but we don't have a way to update it. This is the reason
why we always flush layout on macOS.
Unfortunately, when a menu popup frame is created, widget for the popup is
created synchronously. Then, Cocoa retrieves window level of the widget including
focused element. But this is unsafe to flush the layout. So, we need to stop
flushing layout in this case.
Therefore, this patch moves the `#ifdef` from `TextEvents.h` to
`IMEContentObserver.cpp`, then, makes `nsChildView::GetEditorView()` use
`eQueryContentState` which is the simplest query content event, and finally,
sets `mNeedsToFlushLayout` to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D25912
--HG--
extra : moz-landing-system : lando
This patch introduces a new marionette media test along
with a Youtube test.
To run the Youtube streaming test locally:
./mach marionette-test dom/media/test/marionette/test_youtube.py -vv --gecko-log -
Differential Revision: https://phabricator.services.mozilla.com/D23644
--HG--
extra : moz-landing-system : lando
This gives WorkletImpl a chance to send a message to release worklet thread
objects.
This is used only for PaintWorklet until PaintWorklet uses its own threads.
Differential Revision: https://phabricator.services.mozilla.com/D25353
--HG--
extra : moz-landing-system : lando
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
On process shutdown, the MSG is shut down (and so are other threads) before
the final main thread cycle collection, and so we can't depend on unlink to
notify the worklet before MSG shutdown.
Depends on D25351
Differential Revision: https://phabricator.services.mozilla.com/D25352
--HG--
extra : moz-landing-system : lando
AudioDestinationNode, AudioContext, and Worklet are part of the same cycle.
Any of these may be unlinked before another.
The unlink process for this cycle is the notification that the worklet will no
longer be used, but the worklet uses the destination stream to send a message
to release graph thread objects and so must do this before the stream is
destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D25351
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
In Bug 1448408 ("Don't listen to visibility events"), it became possible to
close a tab without a visibility event to cause transactions to cancel. This
is a longstanding bug that was covered up by the visibility events. This patch
updates the cycle collection code to ensure that transactions get cleared out
safely, and we don't proceed to RejectTransaction (and subsequent code) on
already-cycle-collected objects.
Differential Revision: https://phabricator.services.mozilla.com/D25641
--HG--
extra : moz-landing-system : lando
This patch makes `nsFrameSelection` treat `mozilla::PresShell` directly and
rename `nsFrameSelection::GetShell()` to `nsFrameSelection::GetPresShell()
because of avoiding confusion between `PresShell` vs. `DocShell`.
Differential Revision: https://phabricator.services.mozilla.com/D25719
--HG--
extra : moz-landing-system : lando
This is the last step to be able to call matchMedia on display: none iframes.
This is green, except for some startup preference query tests that I'm going to
address in a blocking bug (making LangGroupFontPrefs global, basically).
The setup is similar to the ShadowRoot one, except we don't eagerly keep the
StyleSet around up-to-date, we only fill it if it ever had a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D23903
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando