Update the refresh command to make it synchronous, and let it return
once the target page has been loaded. This can be accomplished by using
the loadListener object in listener.js.
MozReview-Commit-ID: Lc8QoGFeQrY
--HG--
extra : rebase_source : 1fd914aec1c55fe91a0de773cfd7ff22b5d12167
This refactoring allows us to re-use the same load algorithm for
each command which could trigger a page load. It also takes remoteness
changes into account, and waits until the load has been done.
With this change we no longer check for readyState only, but observe
the necessary DOM events as fired for page unloads and loads. This will
help us to implement the page loading strategy later.
By observing the DOM events, I also expect a small increase of performance
for any kind of page load, given that we now return immediately and do not
have a delay of 100ms at maximum.
MozReview-Commit-ID: IVtO6KgJFES
--HG--
extra : rebase_source : 40f90e3b9d1bf0a2f9123271cd08513769616e41
To delay the page load for our slowly served example page when using the
back or forward commands, the page doesn't have to be put into the browser
cache.
MozReview-Commit-ID: 4xMjR3SakZn
--HG--
extra : rebase_source : 024b8e702d95689defcee7e12496ce531e72d651
Using non-remote pages causes framescripts to be reloaded. We should try
to avoid using those pages as much as possible, and test remoteness
switches in particular tests only. This is to reduce possible hangs.
MozReview-Commit-ID: ICPPkU07KQK
--HG--
extra : rebase_source : 7fdf1f2815790c70f4961cb004a3c066d9a2471e
Since AsyncSpellCheckTestHelper.jsm is test only file, so we have to remove it from whitelist.
MozReview-Commit-ID: J9T6iaUdDgx
--HG--
extra : rebase_source : 6be252f9da67742f9caf63edce037e686a3601ed
reftest cannot use testing-common, so we should include AsyncSpellCheckTestHelper.jsm in reftest.jar.
Previous fix has typo of chrome vs resource. It should be chrome://.
MozReview-Commit-ID: KeyDLjc9AUI
--HG--
extra : rebase_source : 5bf2e6f4105f3437fb3c88410a246e1b85b1bf1d
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : a8553684f8f106c1dfb6e2d9b51df7ebeb15275d
AsyncSpellCheckTestHelper.jsm uses on mochitest and reftest, so we shouldn't ship it in release package
MozReview-Commit-ID: CT8f8DRVwb
--HG--
extra : rebase_source : 4cd803fed4f9215f5237996c83128f5434aaad88
This probably doesn’t make any difference since the only thing we do with this origin is test whether it is user-agent (for internal properties), but this is more correct.
Source-Repo: https://github.com/servo/servo
Source-Revision: 806584da9ac923feaac1d4c22ca030d75c26c31d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 287a852af29532f9c52901c1c5656eb44ddaf5ad
I've commented on the ones that I think are the most tricky. Note that this code
is stress-tested in the style tests (tests/unit/style/rule_tree/bench.rs).
Source-Repo: https://github.com/servo/servo
Source-Revision: dc8ed0d740ede21ed3eb11f8b64813858fc1ca06
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 59c875a2c76115599d9bfb0444946a4f0572f3a5
At this point the only things in the ThreadInfo it uses are the thread name and
id, which are easy to store instead. This gets a step closer to avoiding the
use of ThreadInfo in profiler_get_backtrace().
--HG--
extra : rebase_source : f4feb08ec9fe7880ee43f784c6878c1c04fd3294
StreamSamplesAndMarkers() is the only ThreadInfo method called on
ProfilerBacktrace::mThreadInfo. Furthermore, it doesn't use all that much stuff
from ThreadInfo, and what stuff it does use we can instead pass in as
arguments.
This patch moves StreamSamplesAndMarkers() out of the class. It's a little
ugly, but a necessary precursor for removing ProfilerBacktrace::mThreadInfo and
all the subsequent improvements.
--HG--
extra : rebase_source : 417bda4f29a27c525f7240d3427494dd86b9a868
MozReview-Commit-ID: 6G3zm2jrrMx
This patch needs to use different manifests depending on whether we are building
32-bit or 64-bit Firefox. In order to distinguish between them, I am using
checking for HAVE_64BIT_BUILD in the resource file and embedding the manifests
there.
--HG--
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.32.manifest
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.64.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.32.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.64.manifest
extra : rebase_source : 2d937f47c7b79a4f29a2c2001dec5ed8f00e54bc
Henrik Skupin
Makoto Kato
Michael Froman
Bobby Holley
Tom Ritter
Simon Sapin
Nicholas Hurley
Wes Kocher
Emilio Cobos Álvarez
Sebastian Hengst
ffxbld
Carsten "Tomcat" Book
Timothy Nikkel
Franziskus Kiefer
Nicholas Nethercote
Botond Ballo
Ted Campbell
Tim Nguyen
Aaron Klotz
Ruturaj K. Vartak
Jonathan Kew
Ben Hearsum
Bob Owen
Dale Harvey
Masayuki Nakano
Neil Deakin
Yiren Wang
Olli Pettay
Christoph Kerschbaumer