This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
In particular, gather telemetry to evaluate the impact of unlabeled UTF-8
and how detector-triggered reloads would change if ASCII-only at initial
guess was treated as UTF-8.
Differential Revision: https://phabricator.services.mozilla.com/D140818
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
Implements https://github.com/whatwg/html/issues/6962 . Improves performance
when <meta charset> occurs in head but after the first kilobyte and aligns
behavior better with WebKit and Blink.
The main change is to avoid reloads when meta appears within head but
after the first kilobyte. Prior to this change, Gecko reloaded in that
case (in compliance with the spec!) even though WebKit and Blink did not.
Differences from WebKit and Blink:
* WebKit and Blink honor <meta charset> in <noscript>. This implementation
does not.
* WebKit and Blink look for meta as if the tree builder was unaware of
foreign content. This implementation is foreign content-aware. This
makes a difference for CDATA sections that contain a > before the meta
as well as style and script elements within foreign content. This could
happen if the CDATA section that has mysteriously been introduced around
a what looks like a meta tag also contains another prior tag-looking
run of text.
* This implementation processes rel=preload and speculative loads that are
seen before <meta charset> has been seen. WebKit and Blink instead first
look for the meta and rewind before starting speculative parsing.
* Unlike WebKit, if there is neither an honored meta nor syntax resembling
an XML declaration, detection from content takes place (as in Blink).
* Unlike Blink, if there is neither an honored meta nor syntax resembling
an XML declaration, the detection from content is not dependent of network
buffer boundaries.
* Unlike Blink, detection from content can trigger a reload at the end of
the stream if the guess made at that point differs from the first guess.
(See below for the definition of the input to the first guess.)
Differences from the old spec and Gecko previously:
* Meta inside script and RCDATA elements is no longer honored.
* Late meta is now ignored and no longer triggers a reload.
* Later meta counts as early enough meta: In addition to the previous
meta within the first 1024 bytes, now a meta that started within the first
1024 bytes counts as early enough. Additionally, if by then there hasn't
been a template start tag and head hasn't ended, meta occurring before the
earlier of the end of the head or a template start tag counts as early
enough.
* Meta now counts as not-late even if the encoding label has numeric
character reference escapes.
* Syntax resembling an XML declaration longer than a kilobyte is honored if
there is no honored meta.
* If there is neither an honored meta nor syntax resembling an XML declaration,
the initial chardetng scan is potentially longer than before: the first 1024
bytes, the token spanning the 1024-byte boundary if there is such a token,
and, if by then head hasn't ended and there hasn't been a template start tag
until the end of the template start tag or the end of the token that causes
head to end, ever comes first. However, if the token implying the end of the
head is a text token, bytes only to the end of the previous non-text token is
considered. (This definition avoids depending on network buffer boundaries.)
* XML View Source now uses the code for syntax resembling an XML declaration
instead of expat for extracting the internal encoding label.
Reftest are added as both WPT and Gecko reftests in order to test both http:
and file: URL scenarios. The Gecko tests retain the WPT <link> tags in order
to use the exact same bytes.
An encoding declaration has been added to a number of old tests that didn't
intend to test the new speculation behavior especially in the context of
https://bugzilla.mozilla.org/show_bug.cgi?id=1727750 .
Differential Revision: https://phabricator.services.mozilla.com/D125808
Implements https://github.com/whatwg/html/issues/6962 . Improves performance
when <meta charset> occurs in head but after the first kilobyte and aligns
behavior better with WebKit and Blink.
The main change is to avoid reloads when meta appears within head but
after the first kilobyte. Prior to this change, Gecko reloaded in that
case (in compliance with the spec!) even though WebKit and Blink did not.
Differences from WebKit and Blink:
* WebKit and Blink honor <meta charset> in <noscript>. This implementation
does not.
* WebKit and Blink look for meta as if the tree builder was unaware of
foreign content. This implementation is foreign content-aware. This
makes a difference for CDATA sections that contain a > before the meta
as well as style and script elements within foreign content. This could
happen if the CDATA section that has mysteriously been introduced around
a what looks like a meta tag also contains another prior tag-looking
run of text.
* This implementation processes rel=preload and speculative loads that are
seen before <meta charset> has been seen. WebKit and Blink instead first
look for the meta and rewind before starting speculative parsing.
* Unlike WebKit, if there is neither an honored meta nor syntax resembling
an XML declaration, detection from content takes place (as in Blink).
* Unlike Blink, if there is neither an honored meta nor syntax resembling
an XML declaration, the detection from content is not dependent of network
buffer boundaries.
* Unlike Blink, detection from content can trigger a reload at the end of
the stream if the guess made at that point differs from the first guess.
(See below for the definition of the input to the first guess.)
Differences from the old spec and Gecko previously:
* Meta inside script and RCDATA elements is no longer honored.
* Late meta is now ignored and no longer triggers a reload.
* Later meta counts as early enough meta: In addition to the previous
meta within the first 1024 bytes, now a meta that started within the first
1024 bytes counts as early enough. Additionally, if by then there hasn't
been a template start tag and head hasn't ended, meta occurring before the
earlier of the end of the head or a template start tag counts as early
enough.
* Meta now counts as not-late even if the encoding label has numeric
character reference escapes.
* Syntax resembling an XML declaration longer than a kilobyte is honored if
there is no honored meta.
* If there is neither an honored meta nor syntax resembling an XML declaration,
the initial chardetng scan is potentially longer than before: the first 1024
bytes, the token spanning the 1024-byte boundary if there is such a token,
and, if by then head hasn't ended and there hasn't been a template start tag
until the end of the template start tag or the end of the token that causes
head to end, ever comes first. However, if the token implying the end of the
head is a text token, bytes only to the end of the previous non-text token is
considered. (This definition avoids depending on network buffer boundaries.)
* XML View Source now uses the code for syntax resembling an XML declaration
instead of expat for extracting the internal encoding label.
Reftest are added as both WPT and Gecko reftests in order to test both http:
and file: URL scenarios. The Gecko tests retain the WPT <link> tags in order
to use the exact same bytes.
An encoding declaration has been added to a number of old tests that didn't
intend to test the new speculation behavior especially in the context of
https://bugzilla.mozilla.org/show_bug.cgi?id=1727750 .
Differential Revision: https://phabricator.services.mozilla.com/D125808
We don't stop other animations and such, so seems weird to do it only
for animated images. This line comes from bug 70030, but we no longer
provide "Esc" as a shortcut for Stop(), so it's probably no longer
relevant for users.
Differential Revision: https://phabricator.services.mozilla.com/D125815
Even if the old one isn't, otherwise we can leak.
This doesn't happen at the moment because our printing code creates its
own browser with the initial about:blank loaded (which not Destroy()ing
is fine), and then host the clone in there.
In bug 1666247, for simplify mode the front-end is creating a non-static
document with the simplify mode, then reusing the same docshell for the
static document. That means that we forget the non-static document and
we can leak.
In comment 16 on that bug, the leak comes from a <link rel=stylesheet>
whose SheetLoadData we keep in Document::mPreloadService (which uses
Document::Destroy() to call ClearAllPreloads() and break cycles).
To fix it, check aDocument->IsStaticDocument(), not just
mDocument->IsStaticDocument()... That's the right check since it is the
cloning codepath the one that otherwise doesn't care about what was in
the viewer before.
Differential Revision: https://phabricator.services.mozilla.com/D118809
Even if the old one isn't, otherwise we can leak.
This doesn't happen at the moment because our printing code creates its
own browser with the initial about:blank loaded (which not Destroy()ing
is fine), and then host the clone in there.
In bug 1666247, for simplify mode the front-end is creating a non-static
document with the simplify mode, then reusing the same docshell for the
static document. That means that we forget the non-static document and
we can leak.
In comment 16 on that bug, the leak comes from a <link rel=stylesheet>
whose SheetLoadData we keep in Document::mPreloadService (which uses
Document::Destroy() to call ClearAllPreloads() and break cycles).
To fix it, check aDocument->IsStaticDocument(), not just
mDocument->IsStaticDocument()... That's the right check since it is the
cloning codepath the one that otherwise doesn't care about what was in
the viewer before.
Differential Revision: https://phabricator.services.mozilla.com/D118809
These APIs are entirely unused (aside from one usage in a test, which part 1 in
this patch series removed), so this patch shouldn't impact behavior at all.
Historical note: we briefly removed these APIs once before, in this commit:
https://hg.mozilla.org/mozilla-central/rev/c216ff19d690
...but we brought them back because we had a motivating use case at the time.
We don't have any such motivating use cases any more, though. So, this patch
here is essentially a modernized version of that older commit.
Differential Revision: https://phabricator.services.mozilla.com/D108148
Also, make sure that BFCachePreventionObserver does not fire events for
elements that are part of an anonymous native tree.
Differential Revision: https://phabricator.services.mozilla.com/D103812
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
