This flag can be used to allow gcov for c++ code coverage to run with '--code-coverage' but it prevents 'gcda' artifacts from being uploaded after the tests are done. The 'gcno' upload is allowed with another flag in the code-coverage config called 'MOZ_CODE_COVERAGE'. Removing it's definition will prevent the 'gcno' file from being uploaded.
MozReview-Commit-ID: 1XkH0P4Bh5A
--HG--
extra : rebase_source : 4340e83de39709a7068e469d7f7d6b1e434c9afd
There is no reason for the command to call into the content framescript.
It's only adding overhead and can currently cause hangs if the framescript
gets reloaded.
Instead use the content browser which is always aware of the current URL.
MozReview-Commit-ID: 9Ui7qClFEWJ
--HG--
extra : rebase_source : e428e71ddb66e0152d164f2aebd20efb0593ceec
The underlying code that this method calls from nsIDOMWindowUtils
was removed and has not caused issues in here. This is dead code.
MozReview-Commit-ID: K245et5SmxJ
--HG--
extra : rebase_source : f5345219b9e9ae9299a1884c3424f2d8bfdf3d20
This additionally changes exit() calls with |return VALUE| so
that we are sure to call the destructors and valgrind doesn't complain.
Moreover, this disables the 'new-profile' ping when Firefox is ran
on test profiles.
MozReview-Commit-ID: BlGE9w6yGCL
--HG--
extra : rebase_source : 4149973f832f968a75ec51b245104cb02fd35d4e
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : cd029cdbbcccc1d16f03d63a5f1fdf60be5db4fd
extra : source : a0e257e346ccf3c1db332ec5903241f4eeb9a7ee
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : be2b8b6da5cf78c6263502a6cb422e2de81c742d
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : be2b8b6da5cf78c6263502a6cb422e2de81c742d
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : 19ec875917546abc147b234a815e1a64c204b92a
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
The mochitest-chrome harness sends a custom "contentEvent" event from redirect.html
to a listener in browser-test.js. It is possible for redirect.html to be loaded
and send contentEvent before the listener is set up in browser-test.js. In the
absence of a better synchronization strategy, redirect.html now retries the send
after a few seconds. If the first contentEvent was received, the second will be
ignored; if the first contentEvent was not received, the second should avoid an
intermittent harness hang and timeout.
* marionette: make trace logs safe for windows prompt
The symbols "←" and "→" are encodeed as "?" in the Windows command
prompt. To make the logs from this system useful, use ASCII versions
of the arrows.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 60e7a430dc38a9e1921928c0cd996bb5fc00198b
committer: jgraham <james@hoppipolla.co.uk>
IGNORE BAD COMMIT MESSAGES
--HG--
extra : rebase_source : 261d9d9d73b8e2139dc20bec0985352f2897fabe
extra : amend_source : 4f838fad090337c2a49a3987c3a12d3289e4c7d0
Remove the forbiddenURI pref which was removed in bug 1274893 as well
as browser.safebrowsing.enabled which got renamed in bug 1025965.
Set dummy URLs for all of the network endpoints.
MozReview-Commit-ID: Efk2fv6cC3g
--HG--
extra : rebase_source : 9fbb3eb0fa7f002fe24577a8a0870ec4d1b7cf31
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : 8502233bc79452df4755dea08b04ab6423cf91ed
Step 10 of EME's "Get Supported Capabilities for Audio/Video Type" algorithm
says we can assume default codecs only if a container normatively implies a
specific set of codec and codec constraints. Our code assumes that WebM implies
Vorbis/VP8 and MP4 implies AAC/H.264, but those aren't actually normatively
required by either of these containers' specifications. So we shouldn't assume
these containers imply those codecs.
MozReview-Commit-ID: G9TDOmrjhpp
--HG--
extra : rebase_source : 2f040d76c8cb240359401fe1dc1e3eefa029d77b
Added before_install to handle packages that solve the current 32-bit Linux optimized release issues.
This addition also ensures future changes in dependencies won't cause similar errors.
Defining OS for the i686 target is no longer needed and will break the build if defined.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: c8508c092fd4428a1caa6d8a46a656e940a3ebd1
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : be082b3c0e15f003a33646aa40f03cd348fe43ad
Our linux32-debug build is very slow to startup when running mochitests on aws.
Sometimes we see similar behavior on other linux platforms. Intermittently,
in this environment, startup takes longer than the 120 seconds that marionette
waits, resulting in test failures in bug 1261598. Increasing the marionette
startup timeout to 180 seconds appears to effectively avoid these failures.
For debug builds a delay of 1s is too short. It means that a navigation
command will return when the readyState reaches interactive for an eager
page load strategy. Also due to the slowness of the browser, the getUrl
command which gets run before the readyState check takes too long. Doing
the latter check first fixes it.
MozReview-Commit-ID: D2je04Euwf0
--HG--
extra : rebase_source : 0708fcc1eb5b7198fa45ab995de404db34b64968
This is a stub to have tests to run when the buildbot jobs are defined.
As a note, talos is now e10s only, so we do not need the non-e10s version.
MozReview-Commit-ID: IKDPwKFoHlm
