randomly choose 1% users and their 0.14% page view to measure content blocking.
Differential Revision: https://phabricator.services.mozilla.com/D26130
--HG--
extra : moz-landing-system : lando
This avoids a racy situation early during WGP creation where a null documentURI
can be read incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D26555
--HG--
extra : moz-landing-system : lando
I don't think there's a point in making <link> elements match :visited, and it's
an issue for Chrome docs because some chrome code can run before we have a
profile.
Make the already-existent workaround for localization links work more generally.
There's no interop across browsers here anyhow:
https://github.com/w3c/csswg-drafts/issues/3817
tracks that.
Differential Revision: https://phabricator.services.mozilla.com/D26910
--HG--
extra : moz-landing-system : lando
HTML script tags were being loaded once by the element when it was bound
to the tree and a second time by the PrototypeDocumentContentSink. This
patch disables the script element from loading itself.
Depends on D26822
Differential Revision: https://phabricator.services.mozilla.com/D26823
--HG--
extra : moz-landing-system : lando
Let all chrome privileged XHTML take advantage of the cache and
faster document creation with the prototype document.
Differential Revision: https://phabricator.services.mozilla.com/D26822
--HG--
extra : moz-landing-system : lando
We also take account those values in the case of `Find in page`.
The corresponding web platform tests will be coming from this PR.
https://github.com/web-platform-tests/wpt/pull/8575
Though some of them will not be passed, the failure reason is not related
to this change, I will take a look when the PR gets merged into mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D25915
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
Cmd-line params for the SharedPreferenceSerializer was
duplicated in ContentParent and
SocketProcessHost. Since we'll have a 3rd process (RDD)
using this same code, let's move the repsonsiblity for knowing how to add
these cmdline params into SharedPreferenceSerializer.
Depends on D26567
Differential Revision: https://phabricator.services.mozilla.com/D26568
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Check if the current parent element is an HTML template element and if it
is, append to the document fragment instead of it.
Differential Revision: https://phabricator.services.mozilla.com/D26768
--HG--
extra : moz-landing-system : lando
It seems that in some scenarios, the lifetime of the visual viewport
object exceeds the lifetime of the prescontext. In particular, the
prescontext produced by GetPresContext() can be torn down and a new one
installed. This can leave the visual viewport in a wedged state where it
has scheduled events to be dispatched, but they will never actually be
dispatched, and then subsequent events will not get scheduled. This
patch checks to see if the prescontext has changed, and if so, discards
the old events and reschedules new ones.
Differential Revision: https://phabricator.services.mozilla.com/D26578
--HG--
extra : moz-landing-system : lando
Distinguish broadcast trigger from startup trigger in Remote Settings Uptake events
Differential Revision: https://phabricator.services.mozilla.com/D25585
--HG--
extra : moz-landing-system : lando
- Watch for if a proxy shuts down during init and if so, shutdown the CDM parent
that is being initialized.
- Make ChromiumCDMParent only store a pointer to a ChromiumCDMProxy when it has
successfully initialized. This avoid the lopsided relationship where a if a
ChromiumCDMParent fails to initialize it may keep a pointer to a proxy, but
the proxy will never have a reference to that CDM parent.
Differential Revision: https://phabricator.services.mozilla.com/D26208
--HG--
extra : moz-landing-system : lando
This code is calling other code that expects to be on the main thread, and
having this on the main thread (now that the main thread is a serial event
target) makes it easier to reason about this and other main thread code. I.e.
this cannot be running during other main thread code.
Differential Revision: https://phabricator.services.mozilla.com/D26206
--HG--
extra : moz-landing-system : lando
This gives us greater flexibility in using the main thread member to run
promises.
The site where we obtain the main thread returns a serial event target, so we're
not doing much more work here, we're just keeping the serial event target
interface, rather than converting to an event target interface.
Differential Revision: https://phabricator.services.mozilla.com/D26205
--HG--
extra : moz-landing-system : lando
Also remove unneeded MOZ_COUNT_[CTOR|DTOR] macros. We already get similar
functionality from NS_INLINE_DECL_THREADSAFE_REFCOUNTING.
Differential Revision: https://phabricator.services.mozilla.com/D26204
--HG--
extra : moz-landing-system : lando
This commit adds a smart pointer class that verifies that no dangling
pointers remain after the pointee went out of scope. This verification is
opt-in and can be controlled both statically and dynamically by the pointee.
Differential Revision: https://phabricator.services.mozilla.com/D25200
--HG--
extra : moz-landing-system : lando
Warn instead of asserting since it's possible for decoders to give us 0 by 0
frames here.
Differential Revision: https://phabricator.services.mozilla.com/D26612
--HG--
extra : moz-landing-system : lando
EME key system constants are used with UTF-8 functions where ASCII functions would do
Differential Revision: https://phabricator.services.mozilla.com/D25730
--HG--
extra : moz-landing-system : lando
ImageEncoder::ExtractDataInternal takes a `const nsAString&` for its
options, but flattens it into a null-terminated `nsString` so callees
can take a `char16_t*`. But nearly all of those callees eventually wind
up calling ImageEncoder::GetInputStream, which just constructs an
`nsDependentString` from the passed character pointer.
There's no reason to do all this extra work. We can just pass the
original options reference all the way through the stack and avoid
needless conversions.
Differential Revision: https://phabricator.services.mozilla.com/D26353
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
mJavaDecoder is invalid after the decoder is shut down and should never
be used.
Differential Revision: https://phabricator.services.mozilla.com/D26438
--HG--
extra : moz-landing-system : lando
SaferMultDiv(time, audioScale, videoScale) could easily result in overflow
because all three args are roughly equal, and SaferMultDiv would always do the
multiplication first. The worst-case is then multiplying an int64_t to another
int64_t that have very similar values. Since we represent time here in
microseconds, this would overflow after only 50 minutes.
Differential Revision: https://phabricator.services.mozilla.com/D26494
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
If insertion string ends with ASCII whitespace and there is no following
content in the block, `HTMLEditRules::AdjustWhitespaces()` needs to insert
`<br>` element. It's called only by `HTMLEditRules::AfterEditInner()` and
that does only simple things with `WSRunObject`. Therefore, this moves the
code into `AfterEditInner()`.
For making it adjust the whitespaces, `HTMLEditRules::WillInsertText()` needs
to notify `AfterEditInner()` of dirty range with `mDocChangeRange`. Therefore,
this patch makes it set `mDocChangeRange` manually after inserting composition
string.
On the other hand, there is another bug. `WSRunObject` was designed to treat
only inserting text for `WSRunObject::InsertText()`. I.e., not designed to
treat replacing existing composition string with new string. Therefore,
`WSRunObject::InsertText()` adjusts whitespaces only around start of
composition string. Therefore, if composition string ends with an ASCII
whitespace, it's not replaced with NBSP and that causes:
- failing `WSRunObject::AdjustWhitespaces()` inserts `<br>` element at
`AfterEditInner()` of committing composition.
- then, next composition's first `WSRunObject::InsertText()` removes the
last whitespace due to not followed by `<br>` nor any other content.
Therefore, this patch makes `WSRunObject` takes 2 DOM points to be able to
treat replaced range.
In strictly speaking, the latter change require more changes and tests for
supporting replacement with any other methods. However, it's risky and out
of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D26423
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
HandleOutput() runs on Android binder thread pool and could be preempted
by RemoteDateDecoder task queue. That means ProcessOutput() could be scheduled
after ProcessShutdown() or ProcessFlush(). When that happens, aBuffer is no
long valid and should never be processed, and aSample can be
recycled immediately.
Also assert preconditions of buffers received from Java callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D26189
--HG--
extra : moz-landing-system : lando
roundTripTime can be zero once it has been non-zero this should help with intermitents in WPT and mochitests
Differential Revision: https://phabricator.services.mozilla.com/D25981
--HG--
extra : moz-landing-system : lando
nsFrameLoaderOwner::UpdateRemoteness will recreate the nsFrameLoader for a
piece of content. As part of this, it will unset the cached nsFrameLoader for
the content's nsSubdocumentFrame. However we need to run ShowViewer() for the
new nsFrameLoader as the frame has already been initialized. In addition,
dimensions and position on the new nsFrameLoader need to be set. Usually this
is done after a reflow, but there's no guarantee a reflow will happen after
a UpdateRemoteness operation.
Differential Revision: https://phabricator.services.mozilla.com/D25662
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
Summary:
Currently, `IMEStateManager::SetIMEState` sets hint to the following logic.
- If there is no submit button into form element, set `next`
- If there is submit button, set `search` or `go`
- If there isn't into form element, no hint.
But Chrome sets `next` hint when next focusable element is input that is text
control. So even if there is submit button into form element, we should set
`next` to hint when next focusable element is input that is text/number
control and is in form.
Also, If current focused element isn't in `<form>`, I don't still set hint.
`nsFocusManager::DetermineElementToMoveFocus` may set focus to cross-process
document. So `next` is set when in form and it isn't last element in form.
Reviewers: masayuki
Reviewed By: masayuki
Subscribers: JanH
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D12885
--HG--
extra : rebase_source : f9d297416c046d9b718d9ff925006c162d67f286
extra : histedit_source : d8d946deb81f1f961d002e32720eb9a40a91bf64
Summary: To make setting action hint simple, I would like to move it to static function.
Reviewers: masayuki
Reviewed By: masayuki
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D24832
--HG--
extra : rebase_source : 730451dd56d0d0d2b8208765cac979f54b9745b1
extra : histedit_source : 5775444e938ec3dfa01e8a7a624dea49b785b307
Actually, there is no public method to get next element/content by tabIndex or
TAB key. So I would like to use GetNextTabbableContent from IMEStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D12884
--HG--
extra : rebase_source : 48fa0bb3cd834e9458ad69be1a08f3f32afd1049
extra : histedit_source : 5ce46db9caf5e970e5ed31c0a9e30bd656242684
It's possible to overflow when we do the position calculation, we should only store the position which won't cause the integer overflow when adding it to start time.
Differential Revision: https://phabricator.services.mozilla.com/D25340
--HG--
extra : moz-landing-system : lando
This patch extracts two additional CompositorHitTestInfo flags from the
eDispatchToContent flag; eApzAwareListeners for elements that have
APZ-aware listeners, and eInactiveScrollframe for inactive scrollframe
or unlayerized scrollthumbs. The eDispatchToContent is then renamed to
eIrregularArea to reflect the fact that it is used for irregular-shaped
areas that require main-thread hit-testing.
Additionally, it is important to note that when using the non-WebRender
codepath, all three of these flags still end up gettings squashed into
the "dispatch to content" region on the EventRegions; when APZ
reconstructs a CompositorHitTestInfo it will turn anything in this
region back into an eIrregularArea. So this is a lossy round-trip
conversion for the non-WebRender case. However it should still result in
correct behaviour because the semantics of eIrregularArea result in APZ
relying on the main-thread to do hit-testing and so any APZ-aware
listeners and inactive scrollframes are also handled by the main-thread.
Differential Revision: https://phabricator.services.mozilla.com/D26440
--HG--
extra : moz-landing-system : lando
This permission checking should be handled by PermissionUI.jsm, to be able to apply custom heuristics
for denying the permission and also to be able to "post-prompt" after denying automatically.
Differential Revision: https://phabricator.services.mozilla.com/D25416
--HG--
extra : moz-landing-system : lando
nsIPresShell.h is widely included, so this avoids excessively long rebuilds
when MobileViewportManager.h is modified.
Differential Revision: https://phabricator.services.mozilla.com/D26245
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando