Looks like that any script of web pages don't run in reader mode. If so,
it's safe narrate module to listen to keydown events of non-printable keys
because nobody listens to following keypress events of them. So, it's OK
to stop dispatching following keypress event of keys handled by keydown
event handlers of narrate module.
MozReview-Commit-ID: Agn8H8j8opz
--HG--
extra : rebase_source : 6d609936ce2592e9d23b100e3b875bd115b74c47
This is a temporary fix to allow reopening the tree. This value belongs in saltfs instead, but it's already late and I don't want to have to wait to deploy the changes.
Source-Repo: https://github.com/servo/servo
Source-Revision: 036b9d313937cc1a053c0d94ccea1c2939ff09b0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b03b6774f24897039b2dfd0d3948c899f134f583
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
Currently, if you open the Inspector on some page, then enter RDM, the Inspector
will "reboot" (reload all panels) because it believes the document has reloaded.
However, it's not really true in this case. Instead, it's an artifact of the
pagehide / pageshow events that are triggered when swapping frames like RDM
does. Bug 1438697 adds a chrome-only property that we then use here to
distinguish this case.
MozReview-Commit-ID: Ks42QayVnij
--HG--
extra : rebase_source : 91739a5db2774073e723b1daf43bc5242755fc43
During a frame swap (using the `swapFrameLoaders` API on a frame loader owner),
we dispatch `pagehide` events before swapping and `pageshow` events after
swapping.
For some consumers that watch these events (such as DevTools), it would be
helpful to filter out the ones that sent because of frame swapping. This change
adds a chrome-only `inFrameSwap` property to such events so that we can tell
them apart.
MozReview-Commit-ID: QzIDuaF2zC
--HG--
extra : rebase_source : 3ac15e34c18b648c4cb060e69587e39e4ebaab60
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
num_additional_types is a uint8_t, so its max value is 255. 1 + 255 is
not greater than 256, so the check will pass, but then
num_additional_types += 1 will overflow in the next line.
What I think happened is that bug 1249174 part 6 introduced a bounds
check on an index (which is ok), but then part 8 repurposed this as a
bounds check on the length.
I noticed this because while writing the next patch I ended up with
if (id->num_additional_types > 255)
and then the compiler warned that the check would never fail.
MozReview-Commit-ID: KqiaOyBjj7v
--HG--
extra : rebase_source : 47b20ad2f5e39b05f467cc5b10041070db7fa774
Various strings, like nsISupports, appear many times in XPT data. This
patch adds a cache so we don't write the same string multiple times.
MozReview-Commit-ID: 6buBrXwHqQz
--HG--
extra : rebase_source : 54dea83a9134710c5600828ab68ef3f935f46afd
The name of this class is wrong, but my next patch will make it
actually cache. This patch should not change the behavior.
MozReview-Commit-ID: CMf6Chkeex1
--HG--
extra : rebase_source : a6d5688124b75aef8ed35f811003cf49b8b4e136
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
This adds the 4 digicert CAs to our whitelist as specified in Google's details
on the Chromium version of this plan [1].
[1] c022914eb2/net/data/ssl/symantec/README.md
MozReview-Commit-ID: BR7t1UheKeS
--HG--
rename : security/certverifier/TrustOverride-AppleGoogleData.inc => security/certverifier/TrustOverride-AppleGoogleDigiCertData.inc
extra : rebase_source : 328a3b03a2c40fdf77497430481aa01df6f0059d
Because of the DigiCert-controlled sub-CAs and managed-CAs identified as also
needing to be whitelisted [1], and that those CAs are using an increasing number
of certificates all with different Subjects (but identical public keys) [2][3],
we will have to whitelist on SPKI rather than subject DN.
This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
integration test different, as it now uses a real Google certificate that is
in the whitelist with only a cert verification rather than a full connection
test.
This patch does not add the DigiCert SPKIs to the list; I will do that in its
own patch.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
[2] https://chromium-review.googlesource.com/c/chromium/src/+/916730
[3] https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
MozReview-Commit-ID: 4qVeogDbSb
--HG--
extra : rebase_source : 6912963abe7d05bf2a944fae1209512650763032
This modifies crtshToDNStruct.py to be able to produce SPKI or DN-based lists,
and adds a SPKI-search method to TrustOverrideUtils.h.
This also regenerates the TrustOverride files to use the new script.
MozReview-Commit-ID: BhMoJbYXs7Y
--HG--
rename : security/manager/tools/crtshToDNStruct/crtshToDNStruct.py => security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py
rename : security/manager/tools/crtshToDNStruct/requirements.txt => security/manager/tools/crtshToIdentifyingStruct/requirements.txt
extra : rebase_source : 335d7fc05fa35fbb54ee7ee518b9f4e0c7a00159
The browser console test for imminent distrust relies upon certs inserted
into build/pgo/certs/cert8.db and key3.db [1], and seemed angry when adding new
certs with certutil bumping those to cert9 and key4 formats. Since time is
getting to be of-the-essence with Bug 1434300, I've filed Bug 1439378 to re-
enable this test post-landing.
[1] https://hg.mozilla.org/mozilla-central/rev/98b1272e170c
MozReview-Commit-ID: I4SIiqc5AqH
--HG--
extra : rebase_source : 06295cbed14f2a793162073e707e14026ea69625
The algorithm from https://hg.mozilla.org/mozilla-central/rev/595e27212723
(Bug 1409259) is adapted in this patch from nsNSSCallbacks into the TrustDomain
decisions.
This patch does not change the algorithm to use SPKI matching, nor add the
additional whitelisted intermediates from DigiCert; that will be done in a
separate commit.
This patch also does not update the pre-existing browser chrome test.
MozReview-Commit-ID: 1PdCAqo71bI
--HG--
extra : rebase_source : bc0b1b419dc340a033008d9e9e3b443a2751d5d1
This patch does a few things:
1) It adds a permament test mechanism for the "imminent distrust" trust status
in nsNSSCallbacks: a simple xpcshell test to exercise a clause in the imminent
distrust logic in nsNSSCallbacks' IsCertificateDistrustImminent method.
2) This test removes test_symantec_apple_google_unaffected.js as its
functionality is rolled into the new test_imminent_distrust.js.
3) It updates the Symantec imminent distrust warning algorithm to remove the
validity date exception; this warns of the upcoming distrust for those affected
certs in Firefox 63.
This patch does not attempt to edit the browser chrome test that checks the
console; that is a subsequent patch.
MozReview-Commit-ID: 1HyVLfmEOP7
--HG--
extra : rebase_source : 48c9caae2d26a7e36102b4770c4044101acf0712
In Javascript, we re-clamp timers to ensure they stay the same. Because of double imprecision
sometimes they don't stay the same, and are clamped downwards. If that happens we detect it,
and if we were originally off by an epsilon from a clamped value, we accept the value in the
name of double imprecision.
However, the epsilons were originally chosen somewhat arbitrarily. They worked for small
numbers, where imprecision from doubles were very small. But large doubles have much less
precise fractional parts. So the epsilons were too small for large numbers where the
imprecision was larger.
In Bug 1435296 we stopped reducing the precision of CSS Animations by default, and changed
the test to throw an error if they WERE rounded. After we increased the epsilon in this
patch, we began to see false positives - we were getting values that were not rounded, but
happened to be within the epsilon window and thus appeared rounded. We change the check so
instead of seeing if an Animation is not rounded, and erroring if it is, to accepting any
value.
MozReview-Commit-ID: HnYYo4cuv96
--HG--
extra : rebase_source : 19993a4684a19a646dff43147149e9fc52f2cd0b
Previously, in IsInRanges, aIntervalIndex could have values between -1..length-1.
After the change, the values are in range 0..length, which makes it possible to use unsigned ints and avoid UB.
MozReview-Commit-ID: 39SIzXRHv91
--HG--
extra : rebase_source : d0efebb4bc13694eb7d2048cd2eae2d6386238cf
This was oversight when landing Bug 1419581, coupled with dedicated
testing by Grisha. We don't expose all CONFIG values as DEFINES by
default, and I forgot to add the relevant value to the exposure list.
MozReview-Commit-ID: GUYNWampBAJ
--HG--
extra : rebase_source : f946f2630f2e9120d03b05a4677815e73ab6851a
Andrew McCreight
Masayuki Nakano
Josh Matthews
Valentin Gosu
J. Ryan Stinnett
Hiroyuki Ikezoe
Xidorn Quan
Sebastian Hengst
Felipe Gomes
Jared Wein
Gijs Kruitbosch
nbeleuzu@mozilla.com
J.C. Jones
Michael Ratcliffe
Kit Cambridge
Nico Grunbaum
Thom Chiovoloni
Tom Ritter
shindli
Mark Banner
Rob Wood
Adrian Wielgosik
Ethan Glasser-Camp
Nick Alexander
Jan de Mooij