The site identity security indicator machinery treats connections where the TLS
handshake failed as insecure (also referred to as "unknown identity"). Before
bug 1468222, such cases were easily detectable as the SSLStatus field of the
relevant nsITransportSecurityInfo would be null. When we merged nsISSLStatus
into nsITransportSecurityInfo, we didn't take this differentiation into account.
This patch brings back the prior behavior by checking if the securityInfo's
securityState indicates that the handshake failed (i.e. it is
STATE_IS_INSECURE).
Differential Revision: https://phabricator.services.mozilla.com/D6316
--HG--
extra : moz-landing-system : lando
This allows us to invalidate individual items inside of the mask instead of
treating the mask and it's children as a single item.
Differential Revision: https://phabricator.services.mozilla.com/D6224
This pulls out a nsDisplayMask::IsValidMask that can be used by
blob invalidation to ensure that the mask is drawable.
Differential Revision: https://phabricator.services.mozilla.com/D6502
It isn't possible to trigger this code currently because
the only way to have an inactive 3d transform is with a mask
or filter item and those get handled with a BasicLayerManager.
This becomes necessary once we handle mask items internally.
Differential Revision: https://phabricator.services.mozilla.com/D6222
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
The current code only capitalizes the "keyName" and not the
"modifier.key" property. As such the capitalization gets lost,
because in "event.createKeyboardEventDictionary_()" the
"modifier.key" property gets precedence over "keyName".
To not have to capitalize both at this level, it's better to move
this code directly into "event.createKeyboardEventDictionary_()".
This also makes the method "event.sendSingleKey()" useless, so it
can be removed.
--HG--
extra : rebase_source : 44c69c8856a64ed5aa6f0eac35425e6b2a161ef1
As already mentioned in the comment above the code it is all
done automatically by "event.synthesizeKey()".
--HG--
extra : rebase_source : 4acf138b68be6c13eac6d42d9c1568beb7ad8866
Until now we only supported the internal Unicode to virtual
key mapping at the standard and left location of the keyboard.
This patch adds all the remaining special keys which are
located at the right side and in the numpad area.
This mapping table is somewhat equivalent to the normalized
key translation, but is using the "VK_" prefix.
--HG--
extra : rebase_source : 69030a613fc33e6e3b87eabc44281981c84ee0d7
To avoid confusion with the global "window" object we should
avoid using this name as function argument.
Changes for driver.js are left-out and will be done by the
patch on bug 1311041.
--HG--
extra : rebase_source : f15714af3a422476923d096eb8cb837ae474c675
The global "window" object is mostly a left-over from the copy
of event.js from EventUtils.js, which was included as subscript.
But for Javascript modules, and frame scripts it is not available.
--HG--
extra : rebase_source : 56744e1483f03102c3b930b380db19f0d783ea4e
This change is mainly to avoid the use of SetAllFDsToCloseOnExec, which
has an unavoidable race condition that can leak file descriptors into
child processes. The "Linux" implementation of child process creation,
now that B2G support has been removed, is essentially a generic Unix
fork+dup2+execve which works on BSD (and is already used on Solaris).
3% download protection remote lookup failures are from timeout.
Increase the timeout from 10sec to 15sec to see if this help.
Differential Revision: https://phabricator.services.mozilla.com/D5265
--HG--
extra : moz-landing-system : lando
Telemetry::APPLICATION_REPUTATION_REMOTE_LOOKUP_RESPONSE_TIME can be
used to give us an idea how could we adjust the timeout accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D5264
--HG--
extra : moz-landing-system : lando
Right now no matter it is timeout or not, we will always add the counter
to the false case of APPLICATION_REPUTATION_REMOTE_LOOKUP_TIMEOUT.
We should only set the counter(false) when it is not timeout.
Differential Revision: https://phabricator.services.mozilla.com/D5263
--HG--
extra : moz-landing-system : lando
