The Mozilla string classes don't require manual memory management and
automatically keep track of length, making them a safer choice than raw C
strings.
MozReview-Commit-ID: EwCiiP9EhDr
--HG--
extra : transplant_source : %05%D4%B6s%C1%DBye%2C3%C3%85%DB%22%91h%B4%27%E1l
1. encrypt() and decrypt() are C++ only.
The only callers are in SecretDecoderRing.cpp, and binary add-ons aren't
supported anymore. So, there is no need for these methods to be defined in the
IDL, and they should be treated as private to the nsISecretDecoderRing
implementation.
2. nsISecretDecoderRingConfig has never been implemented.
The interface and implementation are currently just bloat. If there is a need
for specifying the window for prompts in the future, a better way can be devised
then.
MozReview-Commit-ID: 1wXCDTIBJA2
--HG--
extra : transplant_source : %D7%27%5E3%BF%E9%16%0E%A3%8B%E1%8E%ADj%3F%25%B3i%9Al
The interfaces defined within have basically nothing to do with Necko.
MozReview-Commit-ID: 5J4D3w61Yry
--HG--
rename : netwerk/base/nsISecretDecoderRing.idl => security/manager/ssl/nsISecretDecoderRing.idl
extra : transplant_source : %AAP%26%5D%DE%ED%F6Q%C4%5Eia%F1%84T%8D%A7E%8Aw
There are currently two ways of naming files containing the implementation of
interface nsIFoo:
1. nsFoo.(cpp|h) (previous convention)
2. Foo.(cpp|h) (new convention)
nsSDR.(cpp|h) matches neither of these. Renaming the files to follow convention
makes it easier to discover what the files implement, and increases codebase
consistency.
MozReview-Commit-ID: 3ThPxPouiie
--HG--
rename : security/manager/ssl/nsSDR.cpp => security/manager/ssl/SecretDecoderRing.cpp
rename : security/manager/ssl/nsSDR.h => security/manager/ssl/SecretDecoderRing.h
extra : transplant_source : %7D%FC%AD%9C%E8%AD%CFz%FE%F2%D6%1E%A0%0A%06sk%3D%AD%AC
Move the about: handler registration into the content process, and set the flag on the add-on.
MozReview-Commit-ID: Ken10jJH9o8
--HG--
extra : rebase_source : 1b23f082718d1cfd89e89fa37f84af1fc69c2f85
Pages defining CSP response headers used to be a problem for the eyedropper.
Indeed, the eyedropper would take a screenshot of the window with
canvas.drawWindow and then load the resulting data as an Image. But in order
to access the Image() constructor, it would use the content window:
new window.Image(), and that wasn't possible with CSP headers.
With this change, the eyedropper creates an ImageBitmap with
window.createImageBitmap() and that doesn't cause CSP errors, and still works
fine because ImageBitmap are consumable by the eyedropper.
This change also adds a new test to prevent this bug from coming back.
MozReview-Commit-ID: 7f3HCXJtTiv
This adds a few new CSS selectors that are used to move the label to the
top and/or left/right of the eyedropper canvas.
The CSS rules use transform and a quick transition.
The eyedropper highlighter then just makes use of this by adding top, left,
right attributes to the DOM depending on its position.
This also adds a test for this, and while testing, I discovered a bug in
shared/layout/utils.js that I fixed here too. Sometimes, the node passed is
actually a DOCUMENT_NODE and so we must account for this in a couple of places
in this file to avoid JS errors.
MozReview-Commit-ID: H969k3mEDJE
MozReview-Commit-ID: 9qOCYVp4mld
