This allows other UAs to use it, removes duplicated checks, and
increases the chance of us noticing if the spec changes. Some of the
expected values in our mochitest were contrary to the spec.
I checked the new expected failures against the spec and the other UAs.
I filed a spec bug for one group because it was contrary to all UAs
(although IMO the spec makes more sense and the UAs are buggy), and the
others are fixed in the next patch.
MozReview-Commit-ID: 1j11XgfuErB
There hasn't been any traction on this feature, and we keep
paying the maintenance and code size and memory usage penalty
of having this implementation.
We can revive this from VCS history in the future if we decide
to start working on it again. In the mean time, it's better
to remove it.
This patch adds a pref to control whether we dispatch the selection
events for changes in the contents of input and textarea text controls.
The spec for this feature hasn't been written yet, and we need to exclude
this part of the selection API from the part we want to ship.
This was a little tricky to get right. The "spin the event loop" bit is weird
but doing a setTimout to call resolve is already redundant since resolve calls
the promise callbacks on the next turn of the event loop anyway. Basically,
the test just needed to move more stuff to the content process.
MozReview-Commit-ID: KrZZU5reJf7
--HG--
extra : rebase_source : 0817cdefc2e3941a5f59e3e8365d72395d8c4869
This allows other UAs to use it, removes duplicated checks, and
increases the chance of us noticing if the spec changes. Some of the
expected values in our mochitest were contrary to the spec.
I checked the new expected failures against the spec and the other UAs.
I filed a spec bug for one group because it was contrary to all UAs
(although IMO the spec makes more sense and the UAs are buggy), and the
others are fixed in the next patch.
MozReview-Commit-ID: 1j11XgfuErB
They are non-standard aliases for "DragEvent" and "KeyboardEvent" that
are not supported by any other UA, and we would like to drop support.
So first let's stop using them ourselves, so we can use telemetry to see
if any sites are using them.
MozReview-Commit-ID: ICC33ORa2st
- added overrideDPPX to nsIContentViewer
- made CSSStyleSheet and GlobalWindow using the overrideDPPX value
- added unit test with frame check
MozReview-Commit-ID: AOWpGs4vb9H
--HG--
extra : rebase_source : 45d9ae2c9b7aad835b5602e805ec7260c69c05b8
- DOM Mochitests ensure that a dom peer has reviewed
new interfaces listed in the test_interfaces.html file.
- This patch includes the changes to this file that
will require DOM Peer review.
MozReview-Commit-ID: Jll2kKyNBLA
- In order to reduce the size of the following patches
and increase their readability, we rename VRDevice
to VRDisplay here first.
MozReview-Commit-ID: 3pv8scdIi5w
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : rebase_source : 3e4e0b60493397e61283aa1d7fd93d7c197dec29
extra : source : d43c2d5e87f31ff47d7f3ada66c3f5f27cef84a9
This is a silly bug that start() is called twice in this subtest, one
from the load event of the document (by pointerlock_utils.js), the other
is by onload of the iframe. Given the document's load event comes later,
I removed the onload of iframe.
MozReview-Commit-ID: 7TQJVa3xCb9
--HG--
extra : transplant_source : %88%DFF%5E%CD%84%19%01e%A9%18%7E%85%C75%E4%BAb%EC%03
In nsGlobalWindow, we have a static counter for how many popups we've seen
recently. We increment it and decrement it when popups open and close - although
the decrement only occurs once the DocShell is detached, which happens asynchronously.
The test uses a utility that returns Promises for window.open and window.close,
but it uses dom-window-destroyed for resolving close, which happens _before_ the
counter is decremented. The dom-window-destroyed observer queues a runnable which
resolves the Promise.
This means that the test is attempting to open windows before the windows from a
previous test have finished detaching their DocShells (and decrementing the counter),
which means that the attempts to open the window hit the popup limit, which blocks
the popups.
This test switches us to waiting for outer-window-destroyed instead, which gives us
a greater certainty that the decrement has occurred.
MozReview-Commit-ID: 3a7QzxelP0a
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : histedit_source : 5390eeebfe9a2791d9ac8e91ec1dfec4ec7b4118
