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
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
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
Referrerpolicy attribute should be taken with high priority order than
mSpeculationReferrerPolicy
Differential Revision: https://phabricator.services.mozilla.com/D11636
--HG--
extra : moz-landing-system : lando
This is a rebase + manual refcounting on some places, + cleanup of the original
patch in the bug.
Co-authored-by: Nicholas Nethercote <nnethercote@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D11035
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Most of the noise is from the fact that clang-format on parser/html/*.{h,cpp}
reformatted all sorts of stuff. Not running it caused lots of format changes
from the generator... I guess we changed the format rules since the last time
this got run?
MozReview-Commit-ID: IA2G87zUIKN
Adding <meta name="viewport" content="width=device-width"/> to the view-source
document achieves two things when used in a mobile browser, such as Fennec:
1. When word-wrapping is turned off, the page displays at a more readable
initial zoom level.
2. As of now, font inflation (when enabled) kicks in on the document when word-
wrapping is turned on, which leads to the line numbers appearing in a
noticeably smaller font size than the rest of the page.
Adding the above meta viewport header marks the document as "mobile-friendly"
and suppresses font inflation, which means that line numbers will appear
normally even with word-wrapping enabled.
getMathMLSelection() in browser-content.js isn't actually used in Fennec at the
moment, but for consistency we add the meta viewport tag there as well.
MozReview-Commit-ID: K9KVHh7g7TF
--HG--
extra : rebase_source : 1054f712f5420efcd89daeaa2c8c200129544b2a
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
When preloading style link in <head>, we used speculative referrer policy which is
delievered from meta tag and ignored the referrerpolicy attribute.
We should use referrerpolicy attribute with the higher priority
MozReview-Commit-ID: 1rQmBV01jvV
