Consider the case of a very big <style> element, with a few imports on top,
which we cut half-way over the network.
The @import scanner would be likely to have found anything there is to be found,
but we won't process it until we pop the <style> element. It's relatively low
effort to support this use-case by making Scan() return the already-found urls.
Differential Revision: https://phabricator.services.mozilla.com/D47914
--HG--
extra : moz-landing-system : lando
We don't bother handling the nested element case amazingly. We'd instead stop
at the inner <style> element and drop the URLs from the outer.
But I think that's ok. Any good way to test this? I've verified it does the
right thing looking at the CSS loader logs, but... :)
Differential Revision: https://phabricator.services.mozilla.com/D47471
--HG--
extra : moz-landing-system : lando
We don't bother handling the nested element case amazingly. We'd instead stop
at the inner <style> element and drop the URLs from the outer.
But I think that's ok. Any good way to test this? I've verified it does the
right thing looking at the CSS loader logs, but... :)
Differential Revision: https://phabricator.services.mozilla.com/D47471
--HG--
extra : moz-landing-system : lando
The session restore page keeps its restore list within a text input field
so that the values are persisted even if the page is refreshed. When form
elements were loaded with the prototype cache we didn't call
DoneCreatingElement after creating the element, which means the form values
weren't restored.
The list of elements that require DoneCreatingElement and DoneAddingChildren
to be called was in three (now four) different places, so I moved them to
a central spot in nsIContent to share in all locations. This also highlighted
that the check for <output> nodes is missing from the XML content sink.
Differential Revision: https://phabricator.services.mozilla.com/D44866
--HG--
extra : moz-landing-system : lando
The session restore page keeps its restore list within a text input field
so that the values are persisted even if the page is refreshed. When form
elements were loaded with the prototype cache we didn't call
DoneCreatingElement after creating the element, which means the form values
weren't restored.
The list of elements that require DoneCreatingElement and DoneAddingChildren
to be called was in three (now four) different places, so I moved them to
a central spot in nsIContent to share in all locations. This also highlighted
that the check for <output> nodes is missing from the XML content sink.
Differential Revision: https://phabricator.services.mozilla.com/D44866
--HG--
extra : moz-landing-system : lando
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
--HG--
extra : moz-landing-system : lando
Converts varcache prefs content.sink.interactive_parse_time and content.sink.perf_parse_time to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40138
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--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
Since unscoped enums implicitly convert to underlying types, we don't have to change everything at once. It is worth enough to introduce auto-numbering, IMO.
Differential Revision: https://phabricator.services.mozilla.com/D32841
--HG--
extra : moz-landing-system : lando