This will allow these heuristics to be used on mobile.
This depends on GeckoView supporting a JavaScript module
at resource:///modules/BrowserUsageTelemetry.jsm with the
interface described in nsIBrowserUsage.idl. Bug 1573238 has
been filed in order to implement this module on GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D41621
--HG--
extra : moz-landing-system : lando
scrollbars-in-landscape-content.html doesn't fail on environments where we don't
use overlay scrollbars because scrollbars for the visual viewport are not
rendered there.
Differential Revision: https://phabricator.services.mozilla.com/D40770
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
This is what Chrome and Safari do.
See https://webcompat.com/issues/20701#issuecomment-436054739
So for exmaple, if there are two viewport meta tags like this;
<meta name="viewport" content="width=980">
<meta name="viewport" content="initial-scale=1,maximum-scale=1">
We will use "initial-scale=1,maximum-scale=1". Before this change we used to
use merged "width=980,initial-scale=1,maximum-scale=1".
Another example is to replace the content of a single viewport meta tag like this;
<meta id="viewport" name="viewport" content="width=device-width, initial-scale=1">
what will happen when this tag is replaced by below;
<meta id="viewport" name="viewport" content="width=1080">
We will use the replacing one (i.e. "width=1080"), before this change, we used
to use merged "width=1080,initial-scale=1".
As of this commit, we don't properly remove corresponding viewport meta data
when a) viewport meta tag is detached from document and b) `name` attribute is
changed from 'viewport'. These cases will be handled in subsequent commits.
Note that we no longer store invididual viewport meta data in Document::mHeaderData
so that nsIDOMWindowUtils.getDocumentMetadata doesn't work any more for the
invididual viewport meta data, but there is no use cases for them other than
two test cases which are removed in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D38922
--HG--
extra : moz-landing-system : lando
We shouldn't perform an anti-tracking check here, since that may result
in us picking the node principal unintentionally.
Differential Revision: https://phabricator.services.mozilla.com/D37811
--HG--
extra : moz-landing-system : lando
It's never overridden. Also chances are we should remove it and just use
GetDocShell().
Differential Revision: https://phabricator.services.mozilla.com/D37405
--HG--
extra : moz-landing-system : lando
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