This patch contains 2 parts:
- First one is adding a label + icon in the settings panel next to
the Scratchpad tool entry. This is mainly re-adding what was done
for Bug 1527294.
- Second is adding a deprecation warning message *in* the Scratchpad
panel. This is using the NotificationBox that is already used in
the panel.
Both have a link to the deprecated tools MDN page, in which we'll add
a Scratchpad section soon.
Differential Revision: https://phabricator.services.mozilla.com/D43206
--HG--
extra : moz-landing-system : lando
The file only manages the browser console, so we're
making its name reflect what it does.
Differential Revision: https://phabricator.services.mozilla.com/D40441
--HG--
rename : devtools/client/webconsole/hudservice.js => devtools/client/webconsole/browser-console-manager.js
extra : moz-landing-system : lando
ChromeUtils.import still support a second argument as it used to do
when it was Components.utils.import. But this is deprecated and we should
instead always use the returned value.
Differential Revision: https://phabricator.services.mozilla.com/D37708
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
This allows us to drop preprocessing and makes it simpler to add edit menu functionality to any type of document.
Differential Revision: https://phabricator.services.mozilla.com/D21446
--HG--
extra : moz-landing-system : lando
I don't understand how the test ever worked. I think the idea was that each
operation would result in changes to the prefs, because those prefs are the
source of truth for the recent-files list. However, I don't understand why some
tests would not trigger multiple observer callbacks, which should have been a
huge mess.
The new code doesn't observe the prefs at all. Where possible, it waits for an
appropriate promise; in other places it uses `setTimeout()` to wait for the
next tick, relying on the Scratchpad implementation to be done reacting by
then.
Since the original code was event-driven, most tests were split across two
functions. Each test function had the bottom half of one test and the top half
of the next test. The new code uses async/await and can therefore at least
group related functionality into single cohesive test functions. But those test
functions aren't as independent as they look -- most of them still depend on
previous tests to set up the expected starting state.
Differential Revision: https://phabricator.services.mozilla.com/D20759
--HG--
extra : moz-landing-system : lando
Tests can use the promise to avoid racing on the text being available and the
UI ready for interaction.
Differential Revision: https://phabricator.services.mozilla.com/D20758
--HG--
extra : moz-landing-system : lando
I don't understand how the test ever worked. I think the idea was that each
operation would result in changes to the prefs, because those prefs are the
source of truth for the recent-files list. However, I don't understand why some
tests would not trigger multiple observer callbacks, which should have been a
huge mess.
The new code doesn't observe the prefs at all. Where possible, it waits for an
appropriate promise; in other places it uses `setTimeout()` to wait for the
next tick, relying on the Scratchpad implementation to be done reacting by
then.
Since the original code was event-driven, most tests were split across two
functions. Each test function had the bottom half of one test and the top half
of the next test. The new code uses async/await and can therefore at least
group related functionality into single cohesive test functions. But those test
functions aren't as independent as they look -- most of them still depend on
previous tests to set up the expected starting state.
Differential Revision: https://phabricator.services.mozilla.com/D20759
--HG--
extra : moz-landing-system : lando
Tests can use the promise to avoid racing on the text being available and the
UI ready for interaction.
Differential Revision: https://phabricator.services.mozilla.com/D20758
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
Some functions or properties are not used anymore in the
codebase, so we can safely delete them.
Other ones are only used in Scratchpad or VariableView,
which we want to get rid off in the next months. We move
those functions directly in Scratchpad/VariableView.
Differential Revision: https://phabricator.services.mozilla.com/D19377
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This will help getting rid of another usage of Target.form.
And also helps instantiating only one WebConsole client.
Once WebConsole becomes a front, we can replace all the target.activeTab
to target.getFront("console").
Differential Revision: https://phabricator.services.mozilla.com/D14278
--HG--
extra : moz-landing-system : lando
