Our use counter tests force reporting of use counters from documents to
make the tests more deterministic: relying on the default
report-at-document-destruction behavior would introduce any number of
intermittents. However, documents may have any number of external
resource documents, and we have no mechanism for forcing a deterministic
reporting of the use counters from those documents. Relying on those
external resources to have been destroyed (and thereby reported their
use counters) when we examine the values of the use counters in question
is a recipe for intermittent failures.
Therefore, we introduce an optional report kind for use counter
reporting: if a document is reporting its use counters for the purposes
of a test, we will also report the use counters for the document's
external resource documents. This change makes everything more
deterministic.
Our use counter tests force reporting of use counters from documents to
make the tests more deterministic: relying on the default
report-at-document-destruction behavior would introduce any number of
intermittents. However, documents may have any number of external
resource documents, and we have no mechanism for forcing a deterministic
reporting of the use counters from those documents. Relying on those
external resources to have been destroyed (and thereby reported their
use counters) when we examine the values of the use counters in question
is a recipe for intermittent failures.
Therefore, we introduce an optional report kind for use counter
reporting: if a document is reporting its use counters for the purposes
of a test, we will also report the use counters for the document's
external resource documents. This change makes everything more
deterministic.
For simplicity, this test is being added to test_classifier.html which
already has all of the infrastructure necessary for setting up a test
domain as a tracking domain.
It is a preparation for later patch which moves functions from those
classes into StyleSheet. Some of the functions are better defined in
StyleSheetInlines.h.
This commit is generated by the following command:
find . \( -name '*.h' -or -name '*.cpp' \) -not -name '*StyleSheet*' -exec sed -i -b \
-e '/^#include/ s_/\(CSS\|Servo\)StyleSheet\.h_/StyleSheetInlines.h_' \
-e '1,\_^#include "mozilla/StyleSheetInlines.h"_ ! { \_^#include "mozilla/StyleSheetInlines.h"_d }' {} +
MozReview-Commit-ID: 54H5x27Pmso
--HG--
extra : source : e4fe253a8f82c3c58e5191d6af66fb0e85f2df19
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The mobile session store saves the current document resolution in order to restore the previous zoom level when restoring a page. If the display width has changed since the session data was captured (e.g. because the device was rotated), the resolution might have to be scaled appropriately.
Currently, the session store does this scaling by itself by comparing the stored and current window widths, however this implementation is slightly simplified and doesn't cover all use cases, which means some pages can be restored at a wrong zoom level after rotation. To correctly cover all cases, the session store would have to compare viewport widths, too.
Because the MobileViewportManager doesn't wait for the session store to set the restore resolution, the latter has to call setRestoreResolution() as early as possible in order to guarantee that the restore resolution is set before the first paint of the document. Therefore the session store currently calls this after receiving a LocationChange notification. However at that time, the correct viewport for the current document is not yet available, which means the resolution cannot be recalculated by the session store at that point.
Therefore, this patch changes the approach taken and lets the MVM handle all resolution calculations instead. The session store now simply passes the stored previous display dimensions along with the previous document resolution to the MVM, which can then compare them to the current display and viewport widths and scale the resolution appropriately before using it during first paint.
MozReview-Commit-ID: IGxWw87yftK
--HG--
extra : transplant_source : e%8D%BD%26%D2%C3%8E5%E3%2B%C0t%BA%DB%C1%BBs%3F%13%1F
The intention is for the session store to record the current window size and then pass it to the MobileViewportManager for restoring, so the latter can correctly scale the stored resolution if the display width has since changed. However currently all window dimensions available from the JS side are measured in CSS pixels rounded to integers. Transforming those values back into display pixels by multiplying them with "window.devicePixelRatio" (or accessing window.gScreenWidth/Height, which does the same thing internally) unfortunately introduces some rounding errors.
Therefore this patch introduces a new helper method in DOMWindowUtils which allows to access the content window width as measured in device pixels from the JS side, too.
MozReview-Commit-ID: FGNQlXhkgrU
--HG--
extra : transplant_source : %8B%90G%5C%C7%87%B8%8F%0D%EA%3B%FF%3AU%D5%07%81%E7%7Cq
The refresh driver may not be triggered regularly if the page is static.
In that case, we need to ensure a flush is scheduled for fullscreen
change, otherwise the page may get stuck.
MozReview-Commit-ID: c5FhqaIUQW
--HG--
extra : source : 10269de859e1a6b532ecd02fafff205365c51f2b
To test eQueryCharRectArray, I would like to add it to nsIDOMWindowUtils. Also this require unit test and will require external keyboard support on Android
Masayiki asks me more review to smaug this due IDL change.
MozReview-Commit-ID: 24lvQxXBnRX
--HG--
extra : rebase_source : 30788f550a465dc1ee058bf71d56656a89e364c2
extra : histedit_source : 2d2a2d4309b1fde6416408fe0e0d6b0f313898fb
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent. Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.
This patch implements it simply and only in non-e10s mode.
Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).
MozReview-Commit-ID: 34I7vyTUAgO
--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe
Boris Zbarsky
Nathan Froyd
Phil Ringnalda
Cameron McCormack
Ho-Pang
Ehsan Akhgari
Sylvestre Ledru
Andi-Bogdan Postelnicu
George Wright
Ben Kelly
Boris Chiou
Matt Woodrow
James Willcox
Xidorn Quan
Stone Shih
Ryan VanderMeulen
Kartikaya Gupta
Hiroyuki Ikezoe
Nicholas Nethercote
Jimmy Wang
Jonathan Chan
Gregory Szorc
Masayuki Nakano
Nicolas Silva
Matthew Gregan
Jan Henning
Jan de Mooij
Michael Layzell
Bill McCloskey
Makoto Kato
Jan Varga