The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The spec text has been improved a while ago, so I think we should do
this. This keeps the current moz-focusring behavior when the pref is
disabled, but when enabled it becomes effectively an alias of
focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D96697
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
-moz-inert CSS property reflects inert subtrees concept and can be used to implement HTML:dialog element and HTML:inert attribute
Differential Revision: https://phabricator.services.mozilla.com/D81701
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
Some methods on Window are not changed because they are part of public
interface. Method names from widget are also unchanged.
Many "full-screen" in comments are also updated to "fullscreen" instead.
Differential Revision: https://phabricator.services.mozilla.com/D5639
--HG--
extra : moz-landing-system : lando
In order to speed up Required/IsRequired(), instead of querying for the
@required attribute, we're now using the NS_EVENT_STATE_REQUIRED flag to know
whether an element's value is required.
For this to work correctly, we need to set NS_EVENT_STATE_REQUIRED earlier,
that is, in AfterSetAttr(), before any consumer of IsRequired(). We also need
to update or clear our required states when input type changes, since we may
have changed from a required input type to a non-required input type or
vice versa.
Note that NS_EVENT_STATE_REQUIRED/OPTIONAL is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: Bjiby9GqJSB
In order to speed up IsDisabled(), instead of querying for the @disabled
attribute, we're now using the NS_EVENT_STATE_DISABLED flag to know whether an
element is disabled.
It is safe to use the NS_EVENT_STATE_DISABLED flag for the following reasons:
- For form elements, nsGenericHTMLFormElement::IsDisabled() is only called on
form elements that can be disabled; form elements that can't be disabled
overrides IsDisabled() to return false directly.
And, before this patch, NS_EVENT_STATE_DISABLED flag is set by
nsGenericHTMLFormElement::IntrinsicState() if and only if IsDisabled() in all
cases when CanBeDisabled() is true, and when CanBeDisabled() is false then
IsDisabled() is always false and the flag is not set.
- For non form elements, optgroup and option have the flag matching
IsDisabled(). Note that option's IsDisabled() should also refer to optgroup's
(if it exists) disabled state, which was not done before this patch.
For this to work correctly, we need to set NS_EVENT_STATE_DISABLED earlier,
that is, in AfterSetAttr(), before any consumer of IsDisabled().
We also need to update the flag whenever the element's parent (e.g. fieldset or
optgroup) disabled state changes and when moving into/out of a parent
container.
Note that NS_EVENT_STATE_DISABLED/ENABLED is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: KSceikeqvvU
Also implements :link, :visited, and :any-link more efficiently, and stops
matching :-moz-read-only in everything that is not read-write, which is kind of
dumb, and probably creates some artifacts.
MozReview-Commit-ID: 6BQqi7nAWdT
--HG--
extra : rebase_source : 39dc6b481b3a92942dc3732990d8b9040d8e6d84
Since it's not just the EventStateManager that has access to modify
these EventStates bits.
MozReview-Commit-ID: 17EpfQT5M40
--HG--
extra : rebase_source : 6d5f7ecff2d41d66cbc23ea12e08dc6295e29875
Since it's not just the EventStateManager that has access to modify
these EventStates bits.
MozReview-Commit-ID: 17EpfQT5M40
--HG--
extra : rebase_source : 6d5f7ecff2d41d66cbc23ea12e08dc6295e29875
David Parks
Bogdan Tara
Emilio Cobos Álvarez
Noemi Erli
Sean Feng
Mihai Alexandru Michis
Razvan Maries
Alexander Surkov
Narcis Beleuzu
Sylvestre Ledru
Xidorn Quan
Olli Pettay
Ciure Andrei
Cameron McCormack
Edgar Chen
Jessica Jong
Boris Zbarsky
Wes Kocher
Ray Lin
Luke Chang
Nazım Can Altınova
Iris Hsiao
Benjamin Smedberg
Ethan Lin