The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
This increases the default amount of content processes on nightly to 8. It
is nightly only and will not ride the trains.
--HG--
extra : rebase_source : a39b9aa36e10e18b8c8e050d69d639178b6f1a5a
extra : source : d5375325488f449c45dd032bc8167ebebca07497
This updates the test to use a multiple of the default process count rather
than hardcoding 8.
--HG--
extra : rebase_source : 2aa15de90a58e38e480aca5e10f0b680820ecb2c
The 'ipc:content-created' topic doesn't always seem to be propagated to the
browser_force_process_selector.js test. It appears it's not necessary to
actually wait for it, so lets just remove that.
--HG--
extra : rebase_source : 3bd948166ab94007b9e1752fb9a7e934e4341777
browser_preferences_usage.js hardcodes a max value of 15 accesses which doesn't scale well as we increase the number of processes. Instead we'll base the max on a multiplier of the default process count which should avoid bustage in the future but still catch egregious accesses.
--HG--
extra : rebase_source : 9c047b27b6d7a2666f8889ffcee3754762e40987
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
gfritzsche asked me to use this method to add compatibility to measure the time in seconds.
At the moment we are forced to clone `devtools/client/shared/TelemetryStopwatch.jsm` so that we can get it working the way we need.
The problem is that it measure time in ms when using start() finish() etc. and that creates too many entries in our charts and makes them next to impossible to read.
It would be much better if we could measure the time in seconds instead.
Differential Revision: https://phabricator.services.mozilla.com/D4936
--HG--
extra : moz-landing-system : lando
Now that xpcshell no longer uses ParentProcessTargetActor, we can remove comments about it using it.
We can also remove a couple of null checks against docShell that were specific to this usecase.
MozReview-Commit-ID: 67sugv4bZC3
Depends on D7416
Differential Revision: https://phabricator.services.mozilla.com/D7726
--HG--
extra : moz-landing-system : lando
Fix a bug that the current MediaRecorder's state error cases does not match the W3C spec.
pause() and resume() should throw an INVAILD_STATE_ERR only when it is inactive state, making them
independant.
Simply changing if statements is enough because the underlying encoder object (TrackEncoder) will
ignore Suspend/Resume calls when it is already suspended/recording so there won't be side-effects by
multiple pause()/resume() calls.
Differential Revision: https://phabricator.services.mozilla.com/D7910
--HG--
extra : moz-landing-system : lando
Chrome sets both KeyboardEvent.keyCode and KeyboardEvent.charCode of "keypress"
event to same value. On the other hand, our traditional behavior is, sets
one of them to 0.
Therefore, we need to set keyCode value to charCode value if the keypress
event is caused by a non-function key, i.e., it may be a printable key with
specific modifier state and/or different keyboard layout for compatibility
with Chrome. Similarly, we need to set charCode value to keyCode value if
the keypress event is caused by a function key which is not mapped to producing
a character.
Note that this hack is for compatibility with Chrome. So, for now, it's enough
to change the behavior only for "keypress" event handlers in web content. If
we completely change the behavior, we need to fix a lot of default handlers
and mochitests too. However, it's really difficult because default handlers
check whether keypress events are printable or not with following code:
> if (event.charCode &&
> !event.altKey && !event.ctrlKey && !event.metaKey) {
or
> if (!event.keyCode &&
> !event.altKey && !event.ctrlKey && !event.metaKey) {
So, until we stop dispatching "keypress" events for non-printable keys,
we need complicated check in each of them.
And also note that this patch changes the behavior of KeyboardEvent::KeyCode()
when spoofing is enabled and the instance is initialized by initKeyEvent() or
initKeyboardEvent(). That was changed by bug 1222285 unexpectedly and keeping
the behavior makes patched code really ugly. Therefore, this takes back the
old behavior even if spoofing is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D7974
--HG--
extra : moz-landing-system : lando
PuppetWidget::StartPluginIME() calls TabChild::SendStartPluginIME()
with given WidgetKeyboardEvent instance. Then, the keyboard event
will be marked as "posted to remote process" by
ParamTraits<mozilla::WidgetEvent>::Write(). However, the method
sends back the keyboard event to the main process synchronously.
So, we don't want the event is treated as "posted" since the
flag is used to check whether current process handles posted event
*before* the remote process or not.
So, PuppetWidget::StartPluginIME() should restore the cross process
dispatching state with calling
WidgetEvent::ResetCrossProcessDispatchingState(). Unfortunately,
this also clears propagation state of the event too if the event
has already been posted to a remote process and is waiting reply
from the remote process. This shouldn't occur in content
process, however, we should check it with MOZ_ASSERT() for
detecting regressions.
Differential Revision: https://phabricator.services.mozilla.com/D7579
--HG--
extra : moz-landing-system : lando
Bug 1494178 added code to mark samples with 0 encrypted ranges as unencrypted
before they were fed to the CDM. This was to catch issues where we could mark
such unencrypted samples as encrypted. However, the CDM expects certain samples
that are clear to still be marked as encrypted.
Specifically, WebM samples should be marked as encrypted if they are from an
encrypted track and have the signal byte's encryption bit set (a marker for if
the packet is encrypted), even if they have no encrypted ranges.
The WebM demuxer is already doing this. Further inspection and testing of the
mp4 demuxer shows it is behaving in line with Chromium's current mp4 parser,
which we can expect prepares its data sensibly for Widevine.
As the code removed here was added as a safety fallback, but is causing issues,
and as the demuxers already appear to be doing the right thing, the fallback
code can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D8024
--HG--
extra : moz-landing-system : lando
reject Fetch promises with (informative) TypeErrors when decoding fails, per spec
Differential Revision: https://phabricator.services.mozilla.com/D7970
--HG--
extra : moz-landing-system : lando
