The code has mostly moved, but there are a few simplifications:
1) If !GetStreamParser(), then GetChannel() always returns null and hence we
never set isSrcdoc to true. Which is good, because we don't want to apply the
special srcdoc-parsing rules to document.open() stuff. So we just pass false
to setIsSrcdocDocument(): It's the same behavior as before, but a lot clearer.
I've confirmed that code coverage says the "isSrcdoc =
NS_IsSrcdocChannel(channel)" line is unreached in our tests.
2) In the document.write-after-document.open case, aContentType is now always
"text/html" (because that's what document.open sets mContentTypeForWriteCalls
to. So the block checking for it not being "text/html" was dead code (also
confirmed via code coverage results) and I'm just removing it.
Differential Revision: https://phabricator.services.mozilla.com/D30751
--HG--
extra : moz-landing-system : lando
The code here was introduced to fix bug 1053048, but the test there and the
test-case there no longer need this, and it's generally unsound to do stuff that
changes the state of the input from UnbindFromFrame().
I'll file a new bug for the bogus disabled styling in the test-case in a second.
I don't know how to add a test for this (no less because the testcase crashes on
debug builds regardless of this patch, see bug 1551192).
Differential Revision: https://phabricator.services.mozilla.com/D30914
--HG--
extra : moz-landing-system : lando
Currently when we create the video inside a VideoDocument, the PresShell isn't
created yet. This means the video element can't access information about the
compositor, which means it doesn't know whether it can create a hardware
accelerated video decoder, and so we end up falling back to using a software
decoder.
So this patch moves the creation of the video element to slightly later in the
load of a VideoDocument, so that the PresShell is available when we create the
VideoDocument's video element. This means VideoDocuments's video decoder can be
hardware accelerated
Differential Revision: https://phabricator.services.mozilla.com/D30614
--HG--
extra : moz-landing-system : lando
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
In patch2, whenever the media element's readyState is changed back to HAVE_NOTHING, we would reset all cues' active flag and update cue display in order to hide them.
It also means that we should not set any cue's flag when media element's readyState is `HAVE_NOTHING`, so we should abort the `TimeMarchesOn` in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D30390
--HG--
extra : moz-landing-system : lando
`nsIDocumentStateListener` is a scriptable interface and each method may run
any script. So, we should mark them as `can_run_script`. Then, we need to
mark a lot of editing methods because we need to mark
`EditorBase::EndTransactionInternal()` and `EditorBase::DoTransactionInternal()`
as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D30360
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
This appears unused and adds unneeded surface area for these API's to support.
Differential Revision: https://phabricator.services.mozilla.com/D31431
--HG--
extra : source : 9a255864f75ddcf4096b6222d016a914f5a43c8a
This appears unused and adds unneeded surface area for these API's to support.
Differential Revision: https://phabricator.services.mozilla.com/D31431
--HG--
extra : rebase_source : 7886ce8abf398d13432fa9e2ef61cedac41f52b4
extra : histedit_source : dc5404d058bac24d47459bd89d261a506a2a891b
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
They do nothing, if they get parsed, they end up doing the same as text-align:
start, which is the same that we'd get out of GetLogicalAlign if the attribute
wasn't parsed in the first place.
We don't use this attribute for anything else like attribute mapping, so this
should be an idempotent patch.
Differential Revision: https://phabricator.services.mozilla.com/D29360
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsContentUtils::DispatchXULCommand()` because
it guarantees the lifetime of **only** `PresShell` in it. So, we need to check
the lifetime of each argument at each caller here.
Differential Revision: https://phabricator.services.mozilla.com/D29199
--HG--
extra : moz-landing-system : lando
There is the following usage of nsIPresShell:
```
nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShellWeak);
```
So, for changing this to:
```
RefPtr<PresShell> presShell = do_QueryReferent(mPresShellWeak);
```
PresShell should have its own IID.
Differential Revision: https://phabricator.services.mozilla.com/D29197
--HG--
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
swapFrameLoaders relies on frame information, but doesn't ensure it's
up-to-date.
The test for this (test_swapFrameLoaders.xul) is relying right now on one of
flushes from the inner documents to also flush the parent document and thus
ensure there's a frame created.
With the patch for this bug, that flush no longer propagates to the parent
document, and the test fails because we throw in:
https://searchfox.org/mozilla-central/rev/66086345467c69685434dd1c5177b30a7511b1a5/dom/base/nsFrameLoader.cpp#1634
This API could probably be made to work without that requirement, but it's
probably not worth it. For now just flush.
Differential Revision: https://phabricator.services.mozilla.com/D29160
--HG--
extra : moz-landing-system : lando
This subtest (of test_iframe_sandbox_navigation.html) starts intermittently
failing with my first patch of this bug. It relied on the pres-context being
created when sendMouseEvent is called in order to navigate away (we only
navigate away by clicking a link if there's a link handler).
sendMouseEvent calls getBoundingClientRect() which used to do this. It no longer
does though.
I could make sendMouseEvent do that automatically using SpecialPowers or such,
or from the DOMWindowUtils code, but I think I'd prefer not to do that. This is
the only test that wasn't trivially fixable, and this awkwardness can be removed
when bug 1218456 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D28910
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
We have a better type to represent "a coord or nothing", and that's Maybe.
This code is shorter, and I think reads generally better / is less easy to
misuse.
I wrote this on top of bug 1547126 so there shouldn't be conflicts.
Differential Revision: https://phabricator.services.mozilla.com/D28921
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This patch creates new header, `mozilla/PresShellForwards.h`. It should have
all forward declarations of global class/struct in `nsIPresShell.h` and
`mozilla/PresShell.h`.
Additionally, this moves all `enum`s and `constant`s in them into the new file
with changing them to `enum class`es.
This will make other headers which require only specific types in the header
files not include them.
Differential Revision: https://phabricator.services.mozilla.com/D28605
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::region to WidgetMouseEventBase::mRegion
Differential Revision: https://phabricator.services.mozilla.com/D25323
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
Editable elements will no longer get click events for non-primary mouse buttons
since they are being unshipped from the web in favour of auxclick events.
Listen for auxclick as well so middle-click paste still works.
Don't stop propagation after middle-click paste, instead ignore clicks on
contenteditable elements in ClickHandlerChild.
Update test_middle_click_paste.html for the new behaviour.
Also remove the mNoContentDispatch overrides in HTMLInputElement and
HTMLTextAreaElement that were needed for middle-pasting.
Differential Revision: https://phabricator.services.mozilla.com/D26792
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
Instead of only allowing chrome docshells to use the document prototype,
allow any chrome url with chrome privileges to use it.
Differential Revision: https://phabricator.services.mozilla.com/D27744
--HG--
extra : moz-landing-system : lando
- Avoids undesired bluring and focusing of '<input type="number">' and its nested elements.
- Add tests for two scenarios where this could occur.
Differential Revision: https://phabricator.services.mozilla.com/D27684
--HG--
extra : moz-landing-system : lando
This patch adds the number of dropped frames for each step of the process
(read/sink/compositor) and gives us more insight about where frames are
dropped, as opposed to the getVideoPlaybackQuality() API which gives the grand
total.
Differential Revision: https://phabricator.services.mozilla.com/D27488
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
The Picture-in-Picture toggle buttons are now part of the video controls UAWidget
bindings, so we need to construct a UAWidget for the no-controls case for Desktop
to make that toggle available.
Up until now, we've never needed a no-controls UAWidget for Desktop, since we
never needed to show UI in that case.
Depends on D26809
Differential Revision: https://phabricator.services.mozilla.com/D26803
--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
- Remove expectation that 'preventScroll.html' fails.
- Use '[NoInterfaceObject] interface' workaround to simulate missing 'mixin' support.
Differential Revision: https://phabricator.services.mozilla.com/D26922
--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
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
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
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
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
This is closer to what other UAs do, it's simpler, and fixes the bug.
It looks like the complexity of multiple buttons or what not is related to
bug 1188880, which is WONTFIX. We no longer have multiple buttons in the same
file input, so this is better IMO.
Differential Revision: https://phabricator.services.mozilla.com/D26825
There's only one button in a file input. This used to be an
input[type="button"].
There's no point in using more specific rules or such, the regular UA rules just
work, and content can't style this button so it can't be overriden.
This should be an idempotent patch.
Differential Revision: https://phabricator.services.mozilla.com/D26753
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsIControllerCommandTable` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, it's inherited only by nsControllerCommandTable. So, all users
in C++ can treat the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D25727
--HG--
extra : moz-landing-system : lando
`nsICommandManager` isn't implemented by JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, this patch makes all users in C++ use `nsCommandManager` which is
the only implementation of `nsICommandManager`. This avoids QI from
`nsICommandManager` to `nsPICommandUpdater`.
Differential Revision: https://phabricator.services.mozilla.com/D25726
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
This patch makes `nsFrameSelection` treat `mozilla::PresShell` directly and
rename `nsFrameSelection::GetShell()` to `nsFrameSelection::GetPresShell()
because of avoiding confusion between `PresShell` vs. `DocShell`.
Differential Revision: https://phabricator.services.mozilla.com/D25719
--HG--
extra : moz-landing-system : lando
This is the last step to be able to call matchMedia on display: none iframes.
This is green, except for some startup preference query tests that I'm going to
address in a blocking bug (making LangGroupFontPrefs global, basically).
The setup is similar to the ShadowRoot one, except we don't eagerly keep the
StyleSet around up-to-date, we only fill it if it ever had a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D23903
--HG--
extra : moz-landing-system : lando
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
The change to the EventTargetChainItem constructor is because we're changing mTarget to be const (to avoid taking extra stack refs to the EventTarget), so have to set it in the constructor instead of setting it after creating the object.
Differential Revision: https://phabricator.services.mozilla.com/D25813
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
nsContentSink used to decide that it was fine to not notify of silent appends to
a document from the parser if the node was not on our document already.
That's not ok, since if styling or layout have happened already on the document
we're getting inserted into nobody notices them, which is wrong.
Differential Revision: https://phabricator.services.mozilla.com/D25300
--HG--
extra : moz-landing-system : lando
When `nsContentUtils::DispatchInputEvent()` dispatches `input` event, the
editor's value was changed by somebody. In this case, it needs to update
the valid state **and** notify to update the style.
(Note that I'm not sure whether this is right approach.)
Differential Revision: https://phabricator.services.mozilla.com/D25029
--HG--
extra : moz-landing-system : lando
This allows this enumeration to be used from nsIPresShell.h without introducing
a circular dependency.
Its new home in layout/base/ScrollTypes.h, included as mozilla/ScrollTypes.h.
Others similar enums can be added to that file if desired.
This patch also makes ScrollMode an enum class (as it's no longer nested
inside a class) and switches its enumerators to the |eName| naming convention.
Differential Revision: https://phabricator.services.mozilla.com/D24796
--HG--
extra : moz-landing-system : lando
According to the spec [1], `current cues` and `other cues` should only contain cues from `hidden` or `showing` text tracks.
In this patch, text track would be responsible to add `current cues` and `other cues` to the cues list by calling `GetCurrentCuesAndOtherCues()`.
If the text track is disabled, then it won't add any cues to the cues list.
In addition, in order to reduce the size of `other cues` (as actually we don't need to process all cues in the `other cues`), we use the time interval to only get the cues which are overlapping with the time interval.
[1] https://html.spec.whatwg.org/multipage/media.html#time-marches-on
Differential Revision: https://phabricator.services.mozilla.com/D24475
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
In order to trigger the 'onchange' event when resetting the 'date' or
'time' html input elements.
Differential Revision: https://phabricator.services.mozilla.com/D24206
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
Looks like these three APIs slipped through when shipping v1, but no other
vendor supports them, so no reason to be here.
I don't think there's any harm in letting the implementations keep living in
DocumentOrShadowRoot, but let me know if you think otherwise and I'll move them
to Document.
Differential Revision: https://phabricator.services.mozilla.com/D23577
--HG--
extra : moz-landing-system : lando
It would be helpful if we can also print the information in `TextTrack` and `TextTrackCue`.
Differential Revision: https://phabricator.services.mozilla.com/D23449
--HG--
extra : moz-landing-system : lando
Automatically print `TextTrackManager`'s address for the log marco, also update some exist logs.
Differential Revision: https://phabricator.services.mozilla.com/D23448
--HG--
extra : moz-landing-system : lando
Use more general name `WebVTT` for this log module, which will include other debug logs in other files later.
Differential Revision: https://phabricator.services.mozilla.com/D23447
--HG--
extra : moz-landing-system : lando
In this comparison, we only process `hidden` or `showing` track which should not return null TextTrackCueList.
Differential Revision: https://phabricator.services.mozilla.com/D23087
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
Create a new parser (PrototypeDocumentParser) and content sink
(PrototypeDocumentContentSink) that can be used by both XUL and XHTML.
The new parser moves the code from XULDocument that handles creating and
loading a nsXULPrototypeDocument from either the cache or the source
file. Once the parser has finished loading the prototype it notifies the
content sink. The parser is largely a stub and would be better suited
for use as a nsBaseParser, but nsHTMLDocument unfortunately needs an
nsIParser.
The new content sink has the XULDocument code responsible for the
prototype traversal that creates the DOM (XULDocument::ResumeWalk and
friends) and fires off various events.
To unify XUL and XHTML, the XHTML readystate event sequence is used in
XUL. However, the layout path of XHTML loaded from the prototype cache
more closely follows XUL, where frame initializers and layout don't
start until the entire DOM is built.
Differential Revision: https://phabricator.services.mozilla.com/D21236
--HG--
rename : dom/xul/XULDocument.cpp => dom/prototype/PrototypeDocumentContentSink.cpp
rename : parser/moz.build => dom/prototype/moz.build
rename : parser/moz.build => parser/prototype/moz.build
extra : moz-landing-system : lando
We should update cue display everytime when the cues list changed.
In addition, we shouldn't check whether cue is active when we update display, because it's always inactive when the cue has been removed from `TextTrack::RemoveCue()`.
Differential Revision: https://phabricator.services.mozilla.com/D21143
--HG--
extra : moz-landing-system : lando
As the `active cues list` would be automatically contruct when there are any active cues being added or inactive cues being removed, we have no need to use dirty to reset the `active cues list`.
Differential Revision: https://phabricator.services.mozilla.com/D22150
--HG--
extra : moz-landing-system : lando
According to the spec [1], the `current cue` is not equal with the `active cue`, because it might contain non active cues, which might be set to active later during the `TimeMarchesOn`.
The `current cue` should be a list of cues, initialized to contain all the cues of all the hidden or showing text tracks of the media element (not the disabled ones) whose start times are less than or equal to the current playback position and whose end times are greater than the current playback position.
[1] https://html.spec.whatwg.org/multipage/media.html#time-marches-on
Differential Revision: https://phabricator.services.mozilla.com/D22148
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
Based on the current implementation of nsContentUtils::IsPlainTextType(), we
could just call that function again if we need to know whether we're
dealing with plain text content or not later on, but doing it this way ensures
we're always consistent with the current code in StartDocumentLoad(), which
includes some additional sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D20952
--HG--
extra : rebase_source : 5d4606c2c6bc11b2a7f91c221c17c8405fff44b8
extra : amend_source : 6856439650748cdb41e635044c17d6fbf387110b
extra : intermediate-source : 6a5a3077c438a5299fb0752fefb01a081e1f7d96
extra : source : cfb68d7c93bac96fdf979be90116c2de0df76d71
Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.
Differential Revision: https://phabricator.services.mozilla.com/D22081
--HG--
extra : rebase_source : 562588a289632ba2f11db7f3ac8782c26c3b05f8
MediaKeys objects are typically created and associated with an HTMLMediaElement,
however it is possible to create a MediaKeys object and not associate it with an
HTMLMediaElement.
This resulted in an issue where these MediaKeys would keep alive other
components that would assert during bowrser shutdown (see bug 1522547). We
anticipated that MediaKeys associated with an HTMLMediaElement would need to be
shutdown if their owning document became inactive, but were not handling the
case where the keys never became associated with an element.
This patch has the MediaKeys listen directly to their owning document for
activity change. The MediaKeys will shutdown if their document becomes inactive.
This avoids MediaKeys not associated with HTMLMediaElements keeping other
objects alive during browser shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D21983
--HG--
extra : moz-landing-system : lando
Based on the current implementation of nsContentUtils::IsPlainTextType(), we
could just call that function again if we need to know whether we're
dealing with plain text content or not later on, but doing it this way ensures
we're always consistent with the current code in StartDocumentLoad(), which
includes some additional sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D20952
--HG--
extra : moz-landing-system : lando
In order to display blocking icon when the document comes back from the bfcache, we have to notify front end what's the current blocking status.
As the front end side would clear blocking autoplay information when nagivation occurs, and the media might not invoke the play again when they comes back from the bfcache.
Therefore, we should notify front end side that the site is still being blocked, and we should show blocking icon for it.
Differential Revision: https://phabricator.services.mozilla.com/D21582
--HG--
extra : moz-landing-system : lando
Most remaining code in `PresShell::EventHandler::HandleEvent()` is what computes
event target of the event which should be handled on focused content. This
patch moves the part to the new method.
Additionally, moves `nsIPresShell::gKeyDownTarget` to
`EventHandler::sLastKeyDownEventTargetElement` and make it use `StaticRefPtr`.
Finally, for using `Element*` instead of `nsIContent*`, changes the result type
of `Document::GetUnfocusedKeyEventTarget()` to `Element*`.
Differential Revision: https://phabricator.services.mozilla.com/D21195
--HG--
extra : moz-landing-system : lando
This was only used to check for cases when document.open changed the global and
hence elements being inserted into the document need a new reflector. Since
document.open no longer changes the global (as of part 5 of the patches for
this bug), this code is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D17325
--HG--
extra : moz-landing-system : lando
The main behavior changes are:
1) We no longer create a new Window when doing document.open(). We use the
same Window but remove all the event listeners on it and on the existing DOM
tree before removing the document's existing kids.
2) We no longer create a new session history entry. The existing one always
gets replaced instead.
3) We now support document.open on documents that are not in a Window.
The reasons for the various test changes are as follows:
The change to browser_modifiedclick_inherit_principal.js is because we no
longer set the docshell to a wyciwyg URL when document.open() happens and the
test was depending on that to terminate.
browser_wyciwyg_urlbarCopying.js is being removed because it's trying to test
wyciwyg URIs, which no longer exist.
The changes in docshell/test/navigation are because document.open() no longer
affects session history. One of the tests was testing the interactions there
and is being removed; another is being repurposed to just test that
document.open() does not affect history.length.
The change to test_x-frame-options.html is because document.open() now removes
event listeners on the window, which it didn't use to do (and in the specific
case in this test reused the existing inner too, so the listener was still
around in practice). The new behavior matches other browsers.
The removal of test_bug172261.html is because document.open() no longer affects
session history, so you can't go back across it or forward to the "opened"
state, so the situation that test is trying to test no longer exists.
The changes to test_bug255820.html are because reloading a document after
document.open() will now just load the URL of the document that was the entry
document for the open() call, not reload the written content. So there's not
much point testing reload behavior, and in this test it was just reloading the
toplevel test file inside the frames.
The change to test_bug346659.html is because now we no longer create a new
Window on document.open().
The change to test_bug1232829.html is because document.open() (implicit in this
test) no longer adds history entries, so the back() was just leaving the test
page instead of going back across the document.open(). The test is a
crashtest in practice, so might still be testing something useful about how
document.open() interacts with animations.
The change to test_bug715739.html is because the URL of the document after
document.open() is now the URL of the entry document, not a wyciwyg URL, so
reload() has different behavior than it used to.
The change to test_bug329869.html is because now when we go back we're
reloading the original document we had, not doing a wyciwyg load, and the
security info now doesn't include the untrusted script.
The changes to the wpt expectations are removing a bunch of expected failures
now that we pass those tests and disabling some tests that are fundamentally
racy and hence fail randomly. The latter all have github issues filed for the
test problem.
The change to testing/web-platform/tests/common/object-association.js is fixing
tests that were not matching the spec (and were failing in other browsers).
The change to parser-uses-registry-of-owner-document.html is fixing tests that
were not matching the spec (and were failing in other browsers).
The change to document-write.tentative.html is because the test was buggy: it
was using the same iframe element for all its tests and racing loads from some
tests against API calls from other tests, etc. It's a wonder it ever managed
to pass, independent of these patches (and in fact it doesn't pass according to
wpt.fyi data, even in Firefox).
The changes in html/browsers/history/the-history-interface are because
document.open() no longer adds history entries. The test was failing in all
other browsers for the same reason.
The changes in html/browsers/history/the-location-interface are because
reloading a document.open()-created thing now loads the URL of the page that
was the entry document for the open() call. The test was failing in all other
browsers.
The change to reload_document_open_write.html is because we now reload the url
of the document that entered the script that called open() when we reload, not
the written content. Other browsers were failing this test too; Gecko with
the old document.open implementation was the only one that passed.
The change to http-refresh.py is to fix a test bug: it was not returning a
Content-Type header, so we were putting up helper app dialogs, etc.
The change to test_ext_contentscript.js is because we no create a new global
for document.open() calls. Kris Maglione OKed this part.
Differential Revision: https://phabricator.services.mozilla.com/D17323
--HG--
extra : moz-landing-system : lando
Each instance has an instance of Java ExoPlayer that consumes memory in the
limited JVM heap. Too many concurrent players will cause OutOfMemoryError.
Differential Revision: https://phabricator.services.mozilla.com/D20420
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
By adding the Telemetry to measure the number of video/audio which played exactly 7 seconds or more, or less than 7 seconds, after those media has been resumed from blocked state, we can know how many media would meet the Chrome's MEI condition, which could help us to know more about the whole landscape of autoplay media.
In addition, it could help us know how many media are played 'by users intention' because we assume that users are more likely to stop the media if autoplay media is unblocked by accident.
Differential Revision: https://phabricator.services.mozilla.com/D18628
--HG--
extra : moz-landing-system : lando
"blocked" event is used for blocking autoplay. The `AudioChannelAgentBlockedPlay()` returns true when we lost audio focus on Android, so actually we don't need to dispatch "blocked" event.
Differential Revision: https://phabricator.services.mozilla.com/D18627
--HG--
extra : moz-landing-system : lando
`InsertTagCommand::DoCommandParams()` inserts given URL to `href` of `<a>` or
`src` of `<img>`. However, it treats the given URL includes only ASCII
characters. Therefore, we cannot insert URL including non-ASCII characters
with `execCommand("createLink")` nor `execCommand("insertImage")`.
This patch makes `nsHTMLDocument::ExecCommand()` set the param as `nsString`
and makes `InsertTagCommand::DoCommandParams()` retrieve it with `GetString()`.
Differential Revision: https://phabricator.services.mozilla.com/D20615
--HG--
extra : moz-landing-system : lando
