This patch changes the invalid script tag warning to actually include the
invalid tag, which makes it easier to understand what is going wrong.
WebGL pages use invalid types on script elements to store strings. These three
specific strings are used in hundreds of places in our WebGL tests, so don't
warn for them. The first two can be found in WebGL tutorials, so this seems like
an actual convention. "text/something-not-javascript" looks like it is only
used in the WebGL conformance tests, but it is clearly deliberately invalid
so skip warning for it, too, in the interests of reducing warning spam.
I didn't use NS_WARNING_ASSERTION here because that includes the entire
expression that failed, and that is large and not very useful.
Differential Revision: https://phabricator.services.mozilla.com/D212799
A further problem with dynamically inserted import maps was discovered where
sometimes module scripts would never execute. This happens when the script is
still being fetched when the import map is added.
To fix this, cancel all fetching module preloads as well when an import map is
registered and remove them from the module map. In theory this shouldn't be
necessary but I wasn't able to make the tests pass without this step.
For simplicity also remove all module preloads from the scriptloader's list of
preload requests rather than detecting and ignoring them later on.
Differential Revision: https://phabricator.services.mozilla.com/D204202
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
When saving the SRI Hash, we resize the btyecode buffer to the expected size of
the buffer. Previously, after saving the bytecode, the code surrounding
SaveSRIHash introduced the padding necessary for potentially saving bytecode
after.
This patch move the padding into SaveSRIHash, to reduce the overhead of
understanding why the btyecode buffer is being manipulated in what seems to be
out-of-context. Moving it into SaveSRIHash might seems strange but it closer to
other actions to the bytecode buffer which makes it less unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D203131
A further problem with dynamically inserted import maps was discovered where
sometimes module scripts would never execute. This happens when the script is
still being fetched when the import map is added.
To fix this, cancel all fetching module preloads as well when an import map is
registered and remove them from the module map. In theory this shouldn't be
necessary but I wasn't able to make the tests pass without this step.
For simplicity also remove all module preloads from the scriptloader's list of
preload requests rather than detecting and ignoring them later on.
Differential Revision: https://phabricator.services.mozilla.com/D204202
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
A further problem with dynamically inserted import maps was discovered where
sometimes module scripts would never execute. This happens when the script is
still being fetched when the import map is added.
To fix this, cancel all fetching module preloads as well when an import map is
registered and remove them from the module map. In theory this shouldn't be
necessary but I wasn't able to make the tests pass without this step.
For simplicity also remove all module preloads from the scriptloader's list of
preload requests rather than detecting and ignoring them later on.
Differential Revision: https://phabricator.services.mozilla.com/D204202
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
This is the old XPIDL generated header with a few changes
* added the comments from the .idl file
* removed a few unused definitions
* added the license and include guard
Differential Revision: https://phabricator.services.mozilla.com/D202838
This introduces preferences for non-link scripts. See D201997 for the
rationale, test coverage and why there is no behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D202046
The fetchpriority attribute allows web developers to request some
adjustment to the internal priorities when fetching resources. In order
to give some flexibility for experimenting and choosing the values that
work best for Gecko, we will introduce new preferences to control
exactly how the internal priority is adjusted, depending on the value
auto/high/low of the fetchpriority attribute.
This is the first patch of a series introducing such preferences,
focusing on the case `<link rel=preload as=script>`. The following 3
integer preferences are introduced:
```
network.fetchpriority.adjustments.link-preload-script.low
network.fetchpriority.adjustments.link-preload-script.high
network.fetchpriority.adjustments.link-preload-script.auto
```
and are set so that we don't change current behavior (already
covered by tests). A test is also added to verify basic invariants
for such adjustments.
Differential Revision: https://phabricator.services.mozilla.com/D201997
For non-Window globals we pass `true` for `aInitStandardClasses` which results in
`CreateGlobal` calling `JS::InitRealmStandardClasses`.
This affects performance and memory usage and likely isn't necessary. It's also
nicer to not have this difference in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D186216
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
