Rebased due to failing tests on try... built on a failing base.
MozReview-Commit-ID: BiC1pWeml2N
--HG--
extra : rebase_source : 4e57102655d930737950dd571b16632c412e0a3d
Turns out that this is a redux issue that was fixed by the redux update (1441147).
Of course, it is bad practice to manipulate state from a non-react component but if there is no warning we can let it go.
MozReview-Commit-ID: 9Ssus7ypvm2
--HG--
extra : rebase_source : 599dfbdcc2a97c6936499b3088400c069c98e022
This test will cause timeout once we have a microtask checkpoint at the end of
a callback (bug 1193394). Fortunately the test is for the old debugger UI that
we don't ship anymore, so we can just skip it.
MozReview-Commit-ID: AjB1YSNyToD
--HG--
extra : rebase_source : 382dd2533a78cafa41ab4eeea5475d97f65ff6b9
The overlay elements with children of editMenuOverlay.xul are moved into
include files (editMenuCommands.inc.xul and editMenuKeys.inc.xul). For
the other single elements in the overlay, the attributes are inlined
wherever they are used.
MozReview-Commit-ID: 792cuzUvQxT
--HG--
extra : rebase_source : 58e4c05bde16cee873d37c6198de102d048499c2
Importing this object is unnecessary after the updates to the WebIDL console from Bug 1425574
and the follow-ups blocking Bug 1430810. There are still callers that access Console.jsm
to create custom ConsoleAPI objects, but those will be handled separately.
MozReview-Commit-ID: 9ojFxtkpPId
--HG--
extra : rebase_source : 971bf99f709b8d2afe300f3693665724f747aa5e
We keep the XBL binding around for <content>, <constructor>, and <destructor>. This can
eventually be migrated to a Custom Element once we have platform support, but in the meantime
this is a way to get the many thousands of LOC into a JS class.
MozReview-Commit-ID: 1dCQp527yF9
--HG--
extra : rebase_source : 26b833413bab71168aa15e03f0f3803884be3f6b
extra : amend_source : 150cef6748ca8a9e819de0c674fac5966dd574cf
This is enough to get the stylo-enabled build green.
There's still some orange in WPT with stylo disabled (due to interfaces not
exposed and that) that I'll update tomorrow.
Will send a different patch on top of this for that, though I'll land together.
MozReview-Commit-ID: CsN5CM93RUz
This patch does a few things:
1) It removes the symantecRoot and symantec_affected certs from build/pgo/certs'
DB.
2) It upgrades that DB from the old format to SQLite (and this 8/3 to 9/4).
3) It adds a new cert "imminently_distrusted" to that DB for the bc test.
4) It changes the Subject of the immient distrust test to only have the CN
field: this is because certutil reorders C to come after CN, and just like
with the real Symantec certs, I had put C first. So rather than deal with
importing the end entity for the pgo tests, I decided to just make things
simple and change the tested subject.
5) Finally, it re-enables the test that was disabled in Bug 1434300.
MozReview-Commit-ID: Bt2RKyInJje
--HG--
rename : build/pgo/certs/cert8.db => build/pgo/certs/cert9.db
rename : build/pgo/certs/key3.db => build/pgo/certs/key4.db
extra : rebase_source : efceb67ae16f0af617bbd8bec201d52eee0f467d
The hack caused bytecode for block declaration instantiation to be assigned the
location of the first statement inside the block. Unfortunately it made the
source view of the debugger client seem out of sync with the Scopes panel: when
paused after hitting a breakpoint on that line or stepping there, the source
panel showed our location as being inside the block, but the Scopes panel did
not show a block scope.
Two server tests required fixes (also r=jimb, in a separate patch in the same
bug).
test_stepping-08.js assumes that stepping into a function stops at the first
statement in the function. This is usually true. However, now we are removing a
hack, such that our actual behavior for this *particular* function is to stop
at the opening curly brace. This causes the test to fail, without anything
really being broken.
The test is intended to test the interaction of stepping and breakpoints, so
the fix that stays truest to the purpose of the test is to change the debuggee
here to a function with no prologue instructions, so that we don't stop at the
opening brace.
test_blackboxing-01.js is a similar story.
--HG--
extra : rebase_source : 7afc6cc039f313889ee08cdd93ce114691efa1e9
extra : histedit_source : dc274b7cefbb96574c8207a78db05d80238d291d
The onclick handler of the toolbox close button looked like this... spot the deliberate mistake:
```
onClick: () => {
closeToolbox();
focusButton(closeButtonId);
},
```
So we were closing the toolbox and then trying to focus the toolbox's close button.
There is also an obvious race condition with setState inside the toolbox controller not using a callback even though the next line calls a function that uses this.state, which could cause intermittent issues.
MozReview-Commit-ID: 9VRcZw4RvE5
--HG--
extra : rebase_source : 17c21aafe5a72042c23472342c53fd730784a5ae
This is as simple as an upgrade can be. Everything still appears to work but we should ensure try is green before landing.
MozReview-Commit-ID: KjH6nnuK4EY
--HG--
rename : devtools/client/shared/vendor/REDUX_UPGRADING => devtools/client/shared/vendor/REDUX_UPGRADING.md
extra : rebase_source : 12c88e1cad10fc08fcfb2cb829f9969b83b37ca1
