This patch limits the amount of chars we hash and avoids some string copies.
MozReview-Commit-ID: AAcLtTzrYlb
--HG--
extra : rebase_source : 760c0899da9cd5bc5c640be030de20865a45ca98
This adds two properties to the Tab object:
- isArticle indicates whether the document in the tab is likely able to be
rendered in reader mode.
- isInReaderMode indicates if the document in the tab is being rendered in
reader mode.
It also adds a toggleReaderMode() which toggles a tab into and out of reader mode.
There is also a new case in which tabs.onUpdated will fire. When the isArticle
status of a tab changes, an onUpdated event will fire with data {isArticle: boolean}.
MozReview-Commit-ID: AaAQ0V5qm2Z
--HG--
extra : rebase_source : 579fccb76358dc0d333409ed81669cf45576e67f
We added a return error value for compare-locales so that it
can be used in automated checks more easily. For builds, though,
ignore that return value.
Also, mach doesn't like utf-8 encoded output, so let's print
unicode.
MozReview-Commit-ID: L4lzqhBE0By
--HG--
extra : rebase_source : 3a9c612dc99b0f0417eb02c4d8478f1a2f245436
Because nsAString is nicer to work with than char16_t*. The patch relatedly
changes nsIEmbeddingSiteWindow::title and nsIWindowMediator::updateWindowTitle
as well.
--HG--
extra : rebase_source : 0bf332dec3e09af6c39c676f8795b368768a6046
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: L9UE3gXHG4Q
--HG--
extra : source : 37d74bf745b23542251cc6b021d6aabb5ffadea1
extra : intermediate-source : 0402b4bd34c293b44c76de22418899420c8e405b
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: H9I6vNDMdIr
--HG--
extra : rebase_source : cf537a1f65af003c6c4f8919b925b0f305c1dd4d
extra : source : 13b89ce4e6a66c840f82a335c71f5a12938aba22
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: F750v6NN81s
--HG--
extra : rebase_source : 714dd78df0f4c33e23e5b117615bd8fd561674c5
extra : source : 742bda9e6b1ddaf34d09894204ad18ce798b79b7
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: KXJM13VRTB7
--HG--
extra : rebase_source : 3e50b1b3f23248d668d15310554559c39ff792f7
extra : source : 74f5e05877d50a79ec1e5330c227d2ce576a2d90
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
This includes minor shutdown fixes by :asuth as discussed on
https://bugzilla.mozilla.org/show_bug.cgi?id=1047098#c56 and c57.
--HG--
extra : rebase_source : d1a230cc005b2a6a71f16ef84a55851ee2f4f66e
extra : source : e89d2565799b4b02d5ee2c56da8d44dc0067f26a
This patch covers two cases when loading a favicon:
1. Get the request context ID of the document load group, when <link rel="icon"> is found in the page.
2. Use the top level document's request context ID when using the default favicon.
