Turns out we do have saturated arithmetic in mfbt, I just missed it.
Also, use just an uint32 for the heuristic. Text length is a uint32 anyway, and
it's unlikely we want to decide anything when the value is over the max uint32
value.
Differential Revision: https://phabricator.services.mozilla.com/D34496
--HG--
extra : moz-landing-system : lando
This is intended to give a reasonable number that scales with the amount of
content in a website during page load, for scheduling purposes.
This effectively counts the amount of text connected to a document that isn't
likely to be inline style or script.
Potential improvements:
* Maybe have some more heuristics for hidden elements, like presence of the
`hidden` attribute?
* Maybe skip whitespace-only text? This does a pretty good job anyways because
whitespace nodes are usually pretty small (like a couple newlines and
spaces), so they don't add too much to the number. This could be done cheaply if
looking at sSpaceSharedString / sTabSharedString.
* Add some weight to some elements? Maybe images should have a fixed weight,
for example. Though you don't want 0x0 images and such to count... Maybe we
should add to this heuristic out of band when processing image loads or some
such.
* Handle shadow DOM and such better? Right now Shadow DOM and XBL are always
assumed visible as long as they're connected. You _can_ in theory do
something like stash a `<div>` inside a `<style>` element, attach a
ShadowRoot and such, and append a bunch of stuff inside. But I don't think
it's something we should be particularly worried about.
* Probably add some check to CharacterData::AppendText as well? Otherwise this
undercounts when loading big amount of text arrives via the network, for
example, but also I'm not sure we're optimizing for log files and such so it
might be ok.
In any case, this gives us a heuristic that we can iterate on later. This does a
pretty good job at representing the amount of content in the examples over here:
* https://faraday.basschouten.com/mozilla/executionorder/
For example for:
* https://faraday.basschouten.com/mozilla/executionorder/allinlinedual.html
You get an output like the following if you print the heuristic after each bind
operation (and de-duplicating them):
```
0
3 // Some whitespace in <head>
4 // Some whitespace in the <body>.
5
6
7
8
9
10
65547 // Actual content injected by the first script.
65548 // Some more whitespace.
131085 // Actual content injected by the second script.
131087 // Some more whitespace.
```
I'm not a fan of what clang-format has done to my code btw :)
Differential Revision: https://phabricator.services.mozilla.com/D34397
--HG--
extra : moz-landing-system : lando
`aAdjustedValue` of `Document::ConvertToInternalCommand()` is not `nullptr`
when it's called by `ExecCommand()` or `QueryCommandState()`. However,
`QueryCommandState()` does not need the value actually. Therefore, we can move
the input value check from `ExecCommand() to `ConvertToInsernalCommand()`.
Differential Revision: https://phabricator.services.mozilla.com/D29630
--HG--
extra : moz-landing-system : lando
This patch creates `ConvertToInternalCommand()` as the replacement of
`ConvertToMidasInternalCommand()` and `ConvertToMidasInternalCommandInner()`.
It returns `InternalCommandData`. Therefore, every caller can compare
`Command` instead of using `strcmp()`.
Differential Revision: https://phabricator.services.mozilla.com/D29629
--HG--
extra : moz-landing-system : lando
Currently, `Document` converts HTML command (e.g., used by `execCommand()`) to
internal XUL command with array in the global space. However, it requires scan
of the array for every command access.
This patch makes `Document` use hashtable to make the conversion faster.
New mapping info comes from:
- `mXULCommandName` is same as `internalCommandString`
- `mCommand` is mapped in CommandList.h from `mXULCommandName`
- `mGetEditorCommandFunc` is mapped from `mXULCommandName` in:
- https://searchfox.org/mozilla-central/rev/d143f8ce30d1bcfee7a1227c27bf876a85f8cede/editor/libeditor/EditorController.cpp#31-32,34-38,40-41,43,45-51,54-57,67-112
- https://searchfox.org/mozilla-central/rev/75294521381b331f821aad3d6b60636844080ee2/editor/libeditor/HTMLEditorController.cpp#26-28,31-39,48,51-52,55-58,60-63,65-73,76-80,83-88,90-91,93-94,97-100,102-104
- `mExecCommandParam` is converted from `useNewParam` and `convertToBoolean`:
- If corresponding editor command class's `DoCommandParam()` just calls
`DoCommand()`, `ExecCommandParam::Ignore`.
- If `useNewParam` is `true` and `convertToBoolean` is `false`, given value
should be ignored and may set constant instead. In this case,
`ExecCommandParam::Ignore`.
- If `useNewParam` is `false` and `convertToBoolean` is `false`, given value
should be treated as string. In this case, `ExecCommandParam::String`.
- If `useNewParam` is `false` and `convertToBoolean` is `true`, given value
should be treated as bool. In this case, if given command is not a legacy
one, `ExecCommandParam::Boolean`. Otherwise, i.e., if given command
is a legacy one, `ExecCommandParam::InvertedBoolean`.
- Otherwise, `ExecCommandParam::String`.
Differential Revision: https://phabricator.services.mozilla.com/D29628
--HG--
extra : moz-landing-system : lando
This should hopefully allow the parent process to tell whether a given document
is the initial about:blank document.
Differential Revision: https://phabricator.services.mozilla.com/D33542
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
This is similar to this Chromium change:
https://codereview.chromium.org/1155353002
The editing spec doesn't mention editing non-HTML documents, and historically
this is only a feature that WebKit has supported. Supporting this feature
increases the attack surface of the browser without a clear benefit, so it
seems like a good idea to converge on this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32913
--HG--
rename : testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode.html => testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode-xml.xml
extra : moz-landing-system : lando
This API abstracts away the details of the decision on what context should be
partitioned away from the consumers and centralizes the decision making into
the same location in the code base.
Differential Revision: https://phabricator.services.mozilla.com/D29742
--HG--
extra : moz-landing-system : lando
The relevant definition in the spec;
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
Before this change, if both of initial-scale and maximum-scale are negative,
both values are clamped to 0.25. Whereas with this change, negative scale
values are treated as if it's not specified so that initial-scale value is
automatically calculated based on the layout viewport size.
negative-initial-and-maximum-scale.html is a test case for the case.
Also with this change, initial-scale values are going to be clamped to the
range [0.25, 10] during parsing it so that initial-scale-0.html and
initial-scale-100.html need to be modified, now the former is scaled by 0.25x,
the latter is scaled by 10x.
(Before this change, initial-scale=0 and initial-scale=100 were treated as
invalid scale values in nsViewportInfo::ConstrainViewportValues[1])
[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/base/nsViewportInfo.cpp#15,19
Differential Revision: https://phabricator.services.mozilla.com/D32098
--HG--
extra : moz-landing-system : lando
This API abstracts away the details of the decision on what context should be
partitioned away from the consumers and centralizes the decision making into
the same location in the code base.
Differential Revision: https://phabricator.services.mozilla.com/D29742
--HG--
extra : moz-landing-system : lando
We don't need to flush layout in the parent document if the parent and child
documents can't observe each other.
This will also match our behavior in a Fission world.
I'm not attached to the name of the function, better ideas welcome.
Differential Revision: https://phabricator.services.mozilla.com/D28217
We don't need to flush layout in the parent document if the parent and child
documents can't observe each other.
This will also match our behavior in a Fission world.
I'm not attached to the name of the function, better ideas welcome.
Differential Revision: https://phabricator.services.mozilla.com/D28217
We assume in a bunch of other places that user agent stylesheets don't really
change dynamically. It's not clear to me what this code is trying to accomplish
or how is it supposed to work in a multi-process world, but I've left the author
stylesheets code for now...
Also, I'm pretty sure the styleset doesn't handle null sheets, so add a
null-check to the author stylesheets.
Differential Revision: https://phabricator.services.mozilla.com/D28211
Next, we should mark `PresShell::ScrollContentIntoView()` as
`MOZ_CAN_RUN_SCRIPT` because it's used widely.
This patch marks its `PresShell` users, `GoToAnchor()` and `ScrollToAnchor()`,
as `MOZ_CAN_RUN_SCRIPT`. Additionally, this patch moves them from
`nsIPresShell` to `PresShell` because all callers refers `PresShell` directly.
Differential Revision: https://phabricator.services.mozilla.com/D28319
--HG--
extra : moz-landing-system : lando
Just one set of stylesheets is enough. While at it, unify SheetType and Origin.
Differential Revision: https://phabricator.services.mozilla.com/D27564
--HG--
extra : moz-landing-system : lando
Narcis Beleuzu
Cameron McCormack
Andrea Marchesini
Brian Hackett
Boris Zbarsky
Emilio Cobos Álvarez
Masayuki Nakano
Nika Layzell
Zibi Braniecki
Thomas Nguyen
Mihai Alexandru Michis
Ehsan Akhgari
Neil Deakin
prathiksha
Bogdan Tara
Hiroyuki Ikezoe
Christoph Kerschbaumer
Micah Tigley
Brindusan Cristian
Sean Feng
Noemi Erli
Liang-Heng Chen
Sylvestre Ledru
Fariskhi Vidyan
Daniel Varga