It's no need to add 'controls' attribute in this test because it's totally unrelated with navigation and we even have to add extra offset for the cue text in the reference file.
Differential Revision: https://phabricator.services.mozilla.com/D34777
--HG--
extra : moz-landing-system : lando
It would be more convenient to use the pref to dynamically switch vtt debug log on/off without changing any code.
Differential Revision: https://phabricator.services.mozilla.com/D33220
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
When `TabParent::ReconstructWebProgressRequest` was introduced in
31b206e2046f63af31424489e3d61d7761805878, it mistakenly was unconditionally
constructing an `nsIRequest` from the received `RequestData`, even when the URI
was null.
Additionally `ReconstructWebProgressRequest` has been updated to use the Gecko
style for out parameters (accepting an `nsIFoo**` and passing
`getter_AddRefs(...)` instead of `nsCOMPtr<nsIFoo>&`).
Differential Revision: https://phabricator.services.mozilla.com/D34445
--HG--
extra : moz-landing-system : lando
This fixes Bug 1558506 by making it so that the parent process ignores the context menu event
when right-clicking on the remote <browser> hosting the Add-on Options page. Before, we were
handling the event, stopping it from propagating and preventDefault'ing it, and then sending
a message to the parent that ultimately did nothing (since we knew that we didn't want to
display the context menu). Stopping propagation and preventDefault'ing meant that the event
was never fired in the Extension process for the options page.
With the parent process now returning early in the event that it knows that it doesn't want
to be the one to open the context menu, the underlying ContextMenuSpecialProcessChild can
handle the contextmenu event in the extension process, and do the right thing.
Differential Revision: https://phabricator.services.mozilla.com/D34901
--HG--
extra : moz-landing-system : lando
Temporary workaround to use the document element as the root content node
in XHTML pages that have a XUL root element.
Differential Revision: https://phabricator.services.mozilla.com/D34657
--HG--
extra : moz-landing-system : lando
IsMarkingTracer no-longer exists, so remove one comment that refers to it
and fix another comment.
Differential Revision: https://phabricator.services.mozilla.com/D34674
--HG--
extra : moz-landing-system : lando
This test was failing due to the tab closing before a response from the tab was recieved.
It is due to the threadClient closing more quickly. This waits for the last message before closing
Differential Revision: https://phabricator.services.mozilla.com/D32718
--HG--
extra : moz-landing-system : lando
this test was failing because the threadClient was posting messages due to being unable to
find the source map. After investigating, I found that the sourcemap was formatted incorrectly. I do
not know if this was intentional. If it wasn't this fix works. If it was, then we need to find a way
to wait on source map failures, and the test name might need to be updated
Differential Revision: https://phabricator.services.mozilla.com/D32715
--HG--
extra : moz-landing-system : lando
There was an issue where this test was timing out, and due to the way it was written it was
very hard to identify where -- there were many nested promises. I rewrote the test in order to
identify the time out.
Differential Revision: https://phabricator.services.mozilla.com/D32714
--HG--
extra : moz-landing-system : lando
the test `browser_net_params_sorted` may not have been functioning for some time. While
investigating this, I discovered that we were getting an empty array for `actualKeys`. Iterating
over this array returned immediately. As a result the test always passed, even though the shape of
the data changed. I updated this code so that it waits for the dom to be populated with the number
of keys expected. I also updated the test to reflect the data the front end has today.
Differential Revision: https://phabricator.services.mozilla.com/D32713
--HG--
extra : moz-landing-system : lando
There were a few miscellaneous situations in which the test would fail due to a hanging
request. These tests passed in the past because the old way of using the threadActor did not
identify which requests had been responded to.
Differential Revision: https://phabricator.services.mozilla.com/D32711
--HG--
extra : moz-landing-system : lando
Member variables `calledPrepareVMCall_` and `inStubFrame_` served the same purpose for their classes.
Unified them in CacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D33526
--HG--
extra : moz-landing-system : lando
Base commit for bug 1467191. Moves declarations of BaselineCacheIRCompiler and IonCacheIRCompiler
into their respective header files.
Differential Revision: https://phabricator.services.mozilla.com/D33521
--HG--
extra : moz-landing-system : lando
Base commit for patch for bug 1467191 that fixes inconsistencies in
namespace use between BaselineCacheIRCompiler and IonCacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D33516
--HG--
extra : moz-landing-system : lando
The regressor Bug 1248708 inadvertently changed the behavior for opacity 0 text
when implementing -webkit-text-stroke. It treats all opacity 0 text as drawing stroke
even if the stroke property isn't used in the first place.
We should check aParams.textStrokeWidth is actually set before changing draw mode.
Differential Revision: https://phabricator.services.mozilla.com/D34663
--HG--
extra : moz-landing-system : lando
This is consistent with the scroll area events too, and allows us to
remove the WillPaintObserver stuff.
Differential Revision: https://phabricator.services.mozilla.com/D5271
--HG--
extra : moz-landing-system : lando
On MacOSX, especially on MacOS 10.10, the toolbar paint flush happens along
with the urlbar flickers.
Differential Revision: https://phabricator.services.mozilla.com/D34489
--HG--
extra : moz-landing-system : lando