marionette_test.py is a bloated module which contains everything around the Marionette testcase classes.
We should split this up into distinct modules, so each new module covers specific code. The two new modules
introduced are errors, and decorators. This split would also be aligned to the structure of the driver.
To not loose backward compatibility we have to keep the import from marionette_test. It means the new
modules have to live in a sub folder named like that.
MozReview-Commit-ID: DQg55M258ST
--HG--
extra : rebase_source : 2c4150e56b4489518bd1c87b4c3f7cc25e0c5133
- Fixes a crash that occurred when WebVR frames were rendered prior to
setting up the WebGLContext for mirroring back to the 2d display.
MozReview-Commit-ID: Fq4c2287KBL
--HG--
extra : rebase_source : e0e0416f1d6a5f9058c7ed89581b700f32712e72
We currently allow nested event loop to delay ContentChild::RecvShutdown
which in turn might cause content process shutdown hang. This patch
attempts to annotate the crash report that a shutdown hang was after we
have received RecvShutdown but never reach SendFinishShutdown or the
hang happened before or after RecvShutdown.
MozReview-Commit-ID: 8pGqwzLlYpK
--HG--
extra : rebase_source : 78fdec0c29ded1abbd6651c67fe5c97f63555635
nsCSSFrameConstructor::ConstructNonScrollableBlock() has logic to
determine whether to create a block formatting context for a block
frame. I refactor the function to make it reusable by
nsCSSFrameConstructor::ConstructDetailsFrame().
Also, make NS_NewBlockFrame() accept two arguments as other frame
factory functions so that it could be pointed by BlockFrameCreationFunc.
NS_NewBlockFormattingContext is changed accordingly.
The construction for a scrollable DetailsFrame will be further revised
in Part 3.
MozReview-Commit-ID: 8TwG9YMyGva
--HG--
extra : rebase_source : fffdd974df81a809a607491d2534aa8dd2d13ab1
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
--HG--
extra : rebase_source : cc68b975c7d82035410a647ff66eab130055ed04
It wasn't immediately obvious to me that BrowserElementIsReady was correctly
guarding against re-running the browser element scripts in a frame. After more
testing, it was working, but I've added some debug lines for future clarity.
No functionality changes in this patch.
MozReview-Commit-ID: CW4o2TsGKmj
--HG--
extra : rebase_source : 62ec06d4b75f90b3478e403906efaa2f3c3658e2
Except controlling audio focus from gecko, the MediaControlService can also
decide whether needs to request or abandon audio focus.
MozReview-Commit-ID: G3iSYwd24JZ
--HG--
extra : rebase_source : dd29207d8c08176cd7a57f08d3361e4f29c4095a
Remove 'ACTION_REMOVE_CONTROL' because it's as same as 'ACTION_STOP'.
MozReview-Commit-ID: 6KOj8srEuJA
--HG--
extra : rebase_source : 3b92e0f3d6485af4e9be97b1423804401b1496c7
'ACTION_RESUME' should be more suit for its operation.
MozReview-Commit-ID: 4FRHaydVKu5
--HG--
extra : rebase_source : 76b405bf0b7a27f2ea7f27283230df146b71ccfc
In general, the audio competing should only be for audible media and it helps user can focus on one media at the same time. However, we hope to treat all media as the same in the mobile device.
First reason is we have media control on fennec and we just want to control one media at once time. Second reason is to reduce the bandwidth, avoiding to play any non-audible media in background which user doesn't notice about.
MozReview-Commit-ID: yB3181cmVE
--HG--
extra : rebase_source : 0f7bc1d4e9fc3f68e2085f59eb0a313d44a1c058
Now the life time of the MediaControlService would be as same as the Fennec app.
To make code flow more easily, requesting/abandoning the audio focus wouldn't
affect the media control.
We would mainly communicate with the media control via TabEvents.
MozReview-Commit-ID: KT59bII0HuN
--HG--
extra : rebase_source : d8f2c810f24ef6ea72a274db2b432ca8f8876d8e
wrap some code into initialize() and shutdown().
MozReview-Commit-ID: AiyABlyDEME
--HG--
extra : rebase_source : e13f4d1eef46207edd9d8d8cc956c2644f3b1e38
The 'MEDIA_PLAYING_CHANGE' is used for controling media control interface and
the 'AUDIO_PLAYING_CHANGE' is used for showing the tab sound indicator.
MozReview-Commit-ID: 8hZjC77Ju71
--HG--
extra : rebase_source : 3699ea482e89a5c2535defce8ca2689a180d5c49
Previous design is only to request audio focus for audible media, but now we
also request focus for non-audible media.
It's simple that the app should own the focus when users start watching media.
MozReview-Commit-ID: 3eJP26h4kh7
--HG--
extra : rebase_source : b35c4ef7d6560635f428eba445f089abd3844bda
Use 'media-playback' event to control the media control interface on Fennec.
MozReview-Commit-ID: D8SU96RrkbQ
--HG--
extra : rebase_source : 16a13e3b1a450a2949cb62b77a53311797daaaf2
If initializing DXVA fails, we end up destroying the DXVA2Manager on the
decode task queue. The DXVA2Manager asserts that it's destroyed on the
main thread, so we should dispatch a task to destroy it on the appropriate
thread instead of destorying it on the wrong one.
MozReview-Commit-ID: 2pbeMOm74et
--HG--
extra : rebase_source : c4a6871877747d4e04494c638d83b225decaf249
- Use the frame's message manager to direct messages via the
ProxyMessenger to the right tab instead of directly to the tab.
- Put the implementation in a separate file that is only loaded in
child processes (in the future).
- Explicitly list all addon-process specific files in a new category
instead of reusing the content one.
MozReview-Commit-ID: 8oIMx9ol7Tl
--HG--
extra : rebase_source : f93805ecdf44d4607dffc20ffe1cf0cbeb8c86be
Checks what happens before closing a window or removing a frame:
- Tests that sendMessage/connect is received by the extension.
- Tests that any responses from the extension is not received by the
sending script (of the closing context).
MozReview-Commit-ID: 9VwCpRmaZOO
--HG--
extra : rebase_source : f4103a10547835fec2a45086c39b3434937bcdce
Due to asynchronicity or malice we can receive messages for unknown
ProxyContexts. Immediately reject such messages.
(this addresses https://bugzil.la/1288902#c3)
MozReview-Commit-ID: GEgkZC8CUEG
--HG--
extra : rebase_source : 21ddf9c81b0617eb103e382b2df3c4128b5d0516
LegacyExtensionContext should inherit from BaseContext instead of
ExtensionContext, because the latter is moving to a separate process.
Remove the optional `url` parameter because the context is not a frame.
`url` is assigned to `sender.url`, which should only be set for frames.
The sender is only used in extension messaging when `runtime.connect` or
`runtime.sendMessage` are used (where `sender.url` is visible at the
receiver). Since legacy extensions don't send messages, there is no
point at all in setting the `url` value.
MozReview-Commit-ID: FJboNC2SZh0
--HG--
extra : rebase_source : bbfd6670355a3b9985b03b5a203f3b0a19cdfde4
- Introduce a proxy for IPC messages to allow the following APIs
to be run out-of-process (ProxyMessenger):
* runtime.connect
* runtime.sendMessage
* tabs.connect
* tabs.sendMessage
* runtime.onConnect
* runtime.onMessage
- Update getSender in ext-tabs, make it independent of the context
(in particular do not throw an error when a message is received while
the tab is gone), and move it from MessageChannel to ProxyMessenger to
make sure that it works in webext-oop. MessageChannel lives in a child
process, whereas the TabManager (used by getSender) requires data from
the main process.
- Set the third parameter of `addMessageListener` to true in some places
to make sure that messages get delivered even after unloading the
context. This is needed for the next two points.
- Put the `messageManager` property in BaseContext, and let it be set by
`setContentWindow` - runtime.sendMessage/connect and tabs.sendMessage/
connect depends on this property, and using the frame message manager
makes sense.
- Unconditionally use the frame message manager in
runtime.sendMessage/connect instead of sometimes the cpmm.
MozReview-Commit-ID: 4QkPnlMOkjS
--HG--
extra : rebase_source : f2c753a9d396e4b5c40e46cd926024e664372002
To allow ExtensionContext to be refactored, we first need to remove the
dependency of ProxyContext on ExtensionContext.
With the decoupling, we can make setContentWindow unconditional and
remove externallyVisible. Let's clean up later.
MozReview-Commit-ID: 1KmSQpxFTVK
--HG--
extra : rebase_source : 82df61e3f9eadc47b5eddcfa1570f746cb16149e
- Add new responseType RESPONSE_NONE to MessageChannel to signal no
expected reply.
- Modify Port to use MessageChannel instead of message managers.
- Include the `port` object to the disconnect event of ports because
Chrome does it too.
- Replace use of `contentWindow` with `cloneScope` to make the Port
independent of documents.
- Move registration of context destruction from `api()` to the
constructor to make sure that the disconnect listener is properly
removed if for some reason the `api` method is never called.
MozReview-Commit-ID: 9LCo5x1kEbH
--HG--
extra : rebase_source : 226bb0a3cacf5ad22c1f7695f90472a57616dbd6
`this.sender` has a tabId, `sender.tab` has a tab object. Therefore
they are not equal, and as a result messages were sent to the same
frame. Fixed by relying on contextId, which is unique across processes
since bug 1288279.
MozReview-Commit-ID: 8jMoXiBfp6l
--HG--
extra : rebase_source : e9e32c15fb18dbcc5810d2f0076420155f0696a3
callbacks is not an array but a Set, and Object.freeze does not prevent
modification of the list/set. Also, merely overwriting the callback set
is not sufficient to prevent callbacks from being run after the context
is closed (`fireWithoutClone`) because the set being iterated is still
filled with callbacks. And keeping the callbacks around may keep strong
references around and hinder GC.
To fix this, the set of callbacks is cleared (which invalidates the
iterator and ends the loop), and register/unregister are nulled.
Also add an explicit check to prevent callbacks from being registered
after unloading a context.
MozReview-Commit-ID: 4i2ojkbYAX9
--HG--
extra : rebase_source : fc1dacd468f2bc06adbf660dc54b391c573b3dba
the tabs.onUpdated event can fire for many reasons.
I observed a test failure because a faviconUrl change triggered the
onUpdated event, which caused on-updated-dims to be sent too early.
MozReview-Commit-ID: 8YT8hSXnIoo
--HG--
extra : rebase_source : d2ce09a061c7e54f1c9bde78307831dd879dc7af
When restoring a recently closed tab from the corresponding home panel, we normally directly switch to the freshly recreated tab. However if we've entered the home panels through editing mode (as opposed to opening a new tab with about:home), editing mode takes priority and the restored tab is opened in background instead, because we return to the originally selected tab when exiting editing mode.
To fix this inconsistency, we introduce a new parameter for opening tabs from Gecko that cancels editing mode if necessary to allow for directly switching to the new tab.
MozReview-Commit-ID: 4iqPISmtNIx
--HG--
extra : rebase_source : fab9dc911171deef1a984bd96993287d146b370a
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 0cb2c16f484a81b2e77384564973b58ac2d10fb9
Henrik Skupin
kearwood
Kan-Ru Chen
Ting-Yu Lin
J. Ryan Stinnett
Alastor Wu
Chris Pearce
Shing Lyu
Gerald Squelart
Rob Wu
ctai
Jan Henning
Cykesiopka
Mark Hammond
Alfredo.Yang
Wes Kocher
Tooru Fujisawa
Carsten "Tomcat" Book
Julian Descottes
Arseny Malkov