Depends on D21526
This is a request from @mbalfanz in order to keep the naming of the option consistent.
This patch just replaces the l10n string and renames all the places where copyPropertyDeclaration is used in order to avoid confusion.
No functional changes are introduced.
Differential Revision: https://phabricator.services.mozilla.com/D21527
--HG--
extra : moz-landing-system : lando
Now, DevTools server is loaded with a custom loader every time we want to debug chrome
resources. We ensure toggling the "invisibleToDebugger" flag on Loader.jsm which itself
propagates to DevTools Sandboxes.
We added calls to force GC in console test to prevent crashes on Windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D20347
--HG--
extra : moz-landing-system : lando
newSource events used to be sent on the target actors on FF66 and before,
this is no longer the case. But we still have to accept them if we connect
to old remotes, otherwise the events are considered as a method reply
and confuses packet ordering.
Differential Revision: https://phabricator.services.mozilla.com/D21394
--HG--
extra : moz-landing-system : lando
The `yieldingEach` is moved into the only file that
is using it, in canvas debugger, and is not migrated
as the panel will be removed in a few months.
Differential Revision: https://phabricator.services.mozilla.com/D20641
--HG--
extra : moz-landing-system : lando
When removing all declarations from a rule via the Rule view, the authoredText value ends up as an empty string.
This patch ensures that the fallback cssText is not used in that case because that accidentally restores the whole declaration block when re-parsing the text of the rule.
Differential Revision: https://phabricator.services.mozilla.com/D14753
--HG--
extra : moz-landing-system : lando
Now that the base Target class is managing the thread client,
we no longer have to send "newSource" on the target actor, and instead,
listen for newSource directly on the thread client.
We should probably align updatedSource and have this event being emitted on
the thread actor as well.
Depends on D18813
Differential Revision: https://phabricator.services.mozilla.com/D18814
--HG--
extra : moz-landing-system : lando
There is still some tight connection between ThreadClient and Target,
- Target.threadClient, which should ideally disappear in favor of
target.getFront("thread")
- Target.threadClient is manually nullified from ThreadClient.detach,
but that should disappear as well thanks to getFront.
Differential Revision: https://phabricator.services.mozilla.com/D18813
--HG--
extra : moz-landing-system : lando
Depends on D20195
This series of patches depends on the patch from [Bug 1525238](https://bugzilla.mozilla.org/show_bug.cgi?id=1525238)
- adds method to identify a CSS Rule actor by id
- adds context menu option to the Changes panel to allow copying the rule's authored text to the clipboard
Differential Revision: https://phabricator.services.mozilla.com/D20196
--HG--
extra : moz-landing-system : lando
This series of patches depends on the patch from [Bug 1525238](https://bugzilla.mozilla.org/show_bug.cgi?id=1525238)
This patch adds a new method to the StyleRuleActor on the server to expose the full text content of a CSS rule over the protocol to the client. This means exposing the CSS rule's authored text including comments and any nested rules if the target rule is an ancestor rule, like @media or @supports.
There's minor refactoring to include additional rule types for which StyleRuleActors will be created: @supports, @media, @keyframes. These are not explicitly rendered in the Rule view and shouldn't impact it. The Rule view filters for CSS Style Rules, element inline style and has special handling for keyframe at-rules.
Differential Revision: https://phabricator.services.mozilla.com/D20195
--HG--
extra : moz-landing-system : lando
tests; r=ochameau
this migrates the proxy to the new webconsole front events. This resulted in a number of
test failures once the migration was finished, and those were fixed
Differential Revision: https://phabricator.services.mozilla.com/D18834
--HG--
extra : moz-landing-system : lando
this patch introduces events for the webconsoleFront -- not all of them are being listened
to by their subscribers yet, but this is the bulk of the effort to move events to Protocol.js
Differential Revision: https://phabricator.services.mozilla.com/D18832
--HG--
extra : moz-landing-system : lando
initial move of the webconsoleClient to a front. Events do not work yet, but methods do.
Differential Revision: https://phabricator.services.mozilla.com/D18829
--HG--
extra : moz-landing-system : lando
Now, DevTools server is loaded with a custom loader every time we want to debug chrome
resources. We ensure toggling the "invisibleToDebugger" flag on Loader.jsm which itself
propagates to DevTools Sandboxes.
We added calls to force GC in console test to prevent crashes on Windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D20347
--HG--
extra : moz-landing-system : lando
The reason why we use RelaxedAtomBoolis that
ScrollSnapUtils::GetSnapPointForDestination() is called both from the main and
the compositor threads, and the function will have a branch depending on the
pref value.
Differential Revision: https://phabricator.services.mozilla.com/D20101
--HG--
extra : moz-landing-system : lando
There are 2 changes in this patch.
In js-property-provider, we iterate over a Set
and delete item we don't want into instead of
turning the Set into an array, filter on it, and
convert it back to a new Set.
In the autocomplete function, we don't use regexp
anymore in the sort callback as we already have
a way to tell if we're performing an element access.
Differential Revision: https://phabricator.services.mozilla.com/D19471
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
AddonManagergetInstallForURL() has a number of optional arguments, most
of which are passed infrequently. Convert them from positional arguments
to a single options object.
Differential Revision: https://phabricator.services.mozilla.com/D18475
--HG--
extra : rebase_source : 503c09b54fab90cefe69286b05def43ef70074df
When destroying the target, Target.destroy (for local tabs) only calls DebuggerClient.close,
which isn't going to call `detach`. But we still do need to unregister
the tabNavigated/frameUpdate listener to prevent unecessary event from firing.
Depends on D17609
Differential Revision: https://phabricator.services.mozilla.com/D17610
--HG--
extra : moz-landing-system : lando
This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
--HG--
extra : moz-landing-system : lando
This is another very specific issue.
If you have `<img name="attributes"/>` in the dom then `document.attributes` will return the `<img>` tag.
In the source we bail if `!this.rawNode.attributes` but if we are on the document node this returns the image tag. Because the image tag is not a `NamedNodeMap` trying to iterate over the tag throws the error.
There is a test file [here](https://bugzilla.mozilla.org/attachment.cgi?id=9040577).
Differential Revision: https://phabricator.services.mozilla.com/D18340
--HG--
extra : moz-landing-system : lando
But enable it in all tests because a lot of them rely on using it in the
style="" attribute for example, or in inline stylesheets, which will no longer
parse this (even in chrome documents), and we don't want to rewrite all the XUL
and XBL tests.
Differential Revision: https://phabricator.services.mozilla.com/D18027
--HG--
extra : moz-landing-system : lando
When destroying the target, Target.destroy (for local tabs) only calls DebuggerClient.close,
which isn't going to call `detach`. But we still do need to unregister
the tabNavigated/frameUpdate listener to prevent unecessary event from firing.
Depends on D17609
Differential Revision: https://phabricator.services.mozilla.com/D17610
--HG--
extra : moz-landing-system : lando
This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
--HG--
extra : moz-landing-system : lando
Now that form argument is no longer used by any front to set its actor ID,
we can remove this argument.
Have a particular look at:
* devtools/client/shared/test/test-actor-registry.js
which was the last Front to be manually instantiated and need some tweaks,
* canvas head.js to create canvas front via getFront,
* RDM manager.js, which requires the EmulationFront to be self managed.
Depends on D17615
Differential Revision: https://phabricator.services.mozilla.com/D17616
--HG--
extra : moz-landing-system : lando
Ideally, formAttributeName would be a field on the prototype of each front,
but unfortunately, Firefox doesn't support ES Class's fields yet. So it is
put as an instance attribute instead.
This patch streamline the manually set actorID and the retrieval of actor ID
from root or target front's form into `getFront` helper method.
So that all the specific related to the lazy actor is now inside of this helper.
It also moves the special "this.manage(this)" to this helper.
We might be able to followup on this one and finally have only the root front
being self managed. But the initialize method makes it hard.
Note the special tweak made to devtools/client/responsive.html/manager.js
Hopefully this can be removed once the target classes are merged.
Depends on D15832
Differential Revision: https://phabricator.services.mozilla.com/D17615
--HG--
extra : moz-landing-system : lando
Only a couple of special cases where expecting to pass a full form object
as Front's second constructor argument.
Refactor them to ensure calling Front's form method instead in order to align
with typical protocol.js's behavior.
Depends on D17614
Differential Revision: https://phabricator.services.mozilla.com/D15832
--HG--
extra : moz-landing-system : lando
This feature is only used by node and domrulestyle actors and that, only for actor ID.
Instead of this, support this "pass only actor ID rather than full form" feature
in a more dedicated way.
We might followup on that to clarify/simplify doing this: passing only the actor ID
rather than its full form.
Depends on D17613
Differential Revision: https://phabricator.services.mozilla.com/D17614
--HG--
extra : moz-landing-system : lando
Remove all actorid checks in actors and fronts as we never pass a defined `detail` argument in them.
Only domstylerule and node are using detail and that, always with detail="actorid".
Also remove ctx and detail in Front constructor as that's not used by these two actors.
Depends on D17612
Differential Revision: https://phabricator.services.mozilla.com/D17613
--HG--
extra : moz-landing-system : lando
None of our actor define a `formType` in its specification.
This feature has never been used, so remove it and its test.
Differential Revision: https://phabricator.services.mozilla.com/D17612
--HG--
extra : moz-landing-system : lando
r=ochameau,nchevobbe
This patch moves stopListeners to the actor, and removes the need for the callback in the
detach call on the client.
Differential Revision: https://phabricator.services.mozilla.com/D16178
--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
Detect when nodes are scrollable on the actor side, and use this
information to display new [scrollable] markup-badges in the inspector.
Also track this dynimically so badges are added/removed when necessary.
Hide this behind a pref for now, until this gets tested by users and
validated.
Differential Revision: https://phabricator.services.mozilla.com/D17246
--HG--
extra : moz-landing-system : lando
These two tests were using chrome mochitest which forces the test page to be running in chrome and in parent process.
This doesn't reflect typical setup where the page runs unprivileged in content process.
Also, with the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.
Depends on D16826
Differential Revision: https://phabricator.services.mozilla.com/D16827
--HG--
rename : devtools/shared/webconsole/test/test_network_longstring.html => devtools/shared/webconsole/test/browser/browser_network_longstring.js
extra : moz-landing-system : lando
This fixes the issue but because of our virtual canvas implementation and the
fact that reflow events are batched there is quite a bit of flicker and some
drag (see attached video).
Unfortunately, until bug 1509071 is implemented (full screen canvas using
`position:fixed`) we can't really do anything about the flicker... I suppose we
could stop batching reflow events but that would make all of our highlighters
unusably slow.
Differential Revision: https://phabricator.services.mozilla.com/D16988
--HG--
extra : moz-landing-system : lando
If any callback fired by DebuggerClient.close ends up calling close again, it will introduce an infinite loop.
Depends on D15826
Differential Revision: https://phabricator.services.mozilla.com/D15827
--HG--
extra : moz-landing-system : lando
This should be rather safe. We can do more refactoring and renaming once LegacyExtension support is fully removed (ie Fx 65 hits release)
Differential Revision: https://phabricator.services.mozilla.com/D15383
--HG--
extra : moz-landing-system : lando
While trying to implement the invoke getter from
autocomplete popup, it became clear to me that the
initial implementation in js-property-provider wasn't
good enough, as we need to keep track of all the
authorizations the user gave when working on a given
expression.
In order to handle this, JsPropertyProvider now
returns an array of strings representing the path
to the unsafe getter when no matching authorizations
are provided.
If authorizations are provided, we can check for each
properties that the user authorized the execution.
This way, we can handle deep object access after a getter
(e.g. `x.myGetter.foo.bar.baz.entries`) without asking
the user if they want to invoke `myGetter` on each
step of the completion.
This makes handling intermediary getters (e.g.
`x.myGetter.foo.myOtherGetter.bar`) way easier as well.
In the UI, the user will be prompted to invoke the getter one
after the other (if for example they try to complete a pasted
expression which contains multiple getters, they will have
prompts for `myGetter`, and then for `myOtherGetter`).
We wire-up the webconsole client and the webconsole actor for
the autocomplete function, to make them ready for frontend
use.
The existing JsPropertyProvider getters test are updated to
match the change of parameter (invokeGetter -> authorizedEvaluations),
and some tests are added to make sure everything work as intended.
Differential Revision: https://phabricator.services.mozilla.com/D12940
--HG--
extra : moz-landing-system : lando
When provided a string, number or array literals, we use to
simply return the properties from String.prototype, Number.prototype
and Array.prototype.
This is working fine unless the content prototypes are modified.
In order to make it work properly, we retrieve the actual content
prototype.
The js-property-provider unit test is modified to ensure this is
working as expected.
Differential Revision: https://phabricator.services.mozilla.com/D15843
--HG--
extra : moz-landing-system : lando
It was enabled by default in bug 1041833 (for desktops) and
bug 1087562 (for Fennect).
Depends on D15706
Differential Revision: https://phabricator.services.mozilla.com/D15707
--HG--
extra : moz-landing-system : lando
There's a small number of devtools test failures that will be fixed by Alexandre
in bug 1515290. When that lands we can revert this change.
Differential Revision: https://phabricator.services.mozilla.com/D15290
--HG--
extra : moz-landing-system : lando
Depends on D14318. This patch introduces a setInterval to check if
new runtimes have appeared on monitored devices, directly from ADB. This is
one of the scenarios where we don't get an update from ADB. ADB is able to
track devices appearing or disappearing but here we are looking for a new
process, containing a specific string. Out of the box I don't think we can
do anything for this.
Maybe we could ask the devtools server to "broadcast" its presence when it
starts, but at the moment I am not sure how we should implement that.
Differential Revision: https://phabricator.services.mozilla.com/D14324
--HG--
extra : moz-landing-system : lando
Depends on D14709
So far, because we supported only single device, we could correspond to
disconnection by following code. From now, because we will support multi
devices, fix the code that changes the status.
Differential Revision: https://phabricator.services.mozilla.com/D14831
--HG--
extra : moz-landing-system : lando
Depends on D14307. Introduce a placeholder UnknownAdbRuntime extending AdbRuntime.
AdbRuntime implements isUnknown(). This method is used to filter out the unknown runtimes in
webide and about:debugging. (filter will be removed in about:debugging in a patch in the same
queue)
Differential Revision: https://phabricator.services.mozilla.com/D14309
--HG--
extra : moz-landing-system : lando
The model information is duplicated between adb runtime and adb device.
This allows to keep the information in a single place.
Differential Revision: https://phabricator.services.mozilla.com/D14307
--HG--
extra : moz-landing-system : lando
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
This method is only used by target-from-url, it allows to return
a target got one precise top level window and instead of the whole main process.
It looks like it was the very last non-front/still-form target codepath.
Differential Revision: https://phabricator.services.mozilla.com/D14841
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
loadSubScript throws a string, without any stack/location.
Consider all string exceptions as coming from loadSubScript and re-throw a real error
object, coming with the stack of the require call.
Also handle wrong require path with a more explicit error message.
Differential Revision: https://phabricator.services.mozilla.com/D14139
--HG--
extra : moz-landing-system : lando
[Bug 1512634](https://bugzilla.mozilla.org/show_bug.cgi?id=1512634) occurred because the Rule view marks CSS properties as overriden when they are not lowercase. This happens because `ElementStyle.markOverridden()` relies on computed properties. They get built using `CSSProperties.getSubproperties()`. If the input to that method is not lowercase, it doesn't match properties from the CSS database and returns an empty array. This has a side-effect of marking the property as overriden.
In this patch we allow users to type property names in any case, but we validate the lowercase version of them.
Differential Revision: https://phabricator.services.mozilla.com/D14568
--HG--
extra : moz-landing-system : lando
The trait was added in 37 to handle older server,
but given how old it is now, I think it's safe
to remove it.
Differential Revision: https://phabricator.services.mozilla.com/D14424
--HG--
extra : moz-landing-system : lando
This is all the style-system work needed for this.
This implements the concept of legacy shorthands, teaches tests to understand
it, and adds a few more tests for these properties in particular.
The WPT even caught a few WebKit / Blink bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=906336https://bugs.webkit.org/show_bug.cgi?id=191803
This doesn't change the layout behavior for page-break-before: always, since
it'd stop breaking in multicol and such. Similarly, break-before / break-after:
column and page still behave the same, I'll file followups for those given
comment 22.
Differential Revision: https://phabricator.services.mozilla.com/D12211
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
In Bug 1462394, we moved the autocomplete data handling
out of the JsTerm to the Redux store. In the process, we
regress some cases like `await n`, which should display
`navigator`, but isn't anymore when the user types the
whole sequence. Ctrl+Space would still show the popup,
which indicates that the issue is not on the server-side.
This issue is caused because our new code decides that
we should hit the cache when typing the `n`, and there's
nothing in the cache.
Previously, we were clearing the cache as soon as the input
last string wasn't alphanumeric, which we don't anymore.
To fix that, instead of relying on the last string of the
input (which could be wrong in cases like `x.["hello `), we
clear the cache when the autocomplete service returns a null
`matches` property.
In the JsPropertyProvider, we use to return null whenever
there isn't any search done (incorrect input, empty match prop, …).
So it seems like a good idea to bust the cache when the
server returns null.
This requires some changes to the autocomplete service, as well
as some in jsPropertyProvider (e.g. to handle `await `).
Tests are added both on the client and the frontend to make sure
we don't regress this (those tests fail without the actual fix).
Differential Revision: https://phabricator.services.mozilla.com/D13231
--HG--
extra : moz-landing-system : lando
Depends on D13137. I could use help to write the test in a better.
I believe there is a cleaner way to create the front here?
I also had other suggestions for making the fronts more robust in the bug.
Let me know if you think I should try to investigate them more.
Differential Revision: https://phabricator.services.mozilla.com/D13138
--HG--
extra : moz-landing-system : lando
Ideally, it would use TargetFactory. But as that's mochitest chrome,
we don't have natural access to gBrowser/firefox tab.
MozReview-Commit-ID: 4nrfFZu6jAU
Depends on D12734
Differential Revision: https://phabricator.services.mozilla.com/D12735
--HG--
extra : moz-landing-system : lando
For now, we only pass { actor } for all tab target fronts created via DebuggerClient.attachTarget,
whereas parent process target fronts were passing the full form from RootFront.getProcess.
MozReview-Commit-ID: 1H2NxFv8glY
Differential Revision: https://phabricator.services.mozilla.com/D12730
--HG--
extra : moz-landing-system : lando
We were dipatching the "connect" request manually, whereas we should be using
protocol.js specifications. It also help getting rid of another use of "form"
instead of "front"/activeTab in Target class.
MozReview-Commit-ID: IOH4mDprAVL
Depends on D12577
Differential Revision: https://phabricator.services.mozilla.com/D12578
--HG--
extra : moz-landing-system : lando
I did a dedicated patch for converting both about:debuggings as it is slightly more
complex as we have to tweak redux data, wrappers, mocks.
This patch also convert a manual "reload" request being done by about:debugging
and instead use protocol.js front to do it.
Also, I moved isLegacyTemporaryExtension to the front as it depends on accessing the form
and it should be better to keep form processing to the fronts, if possible.
MozReview-Commit-ID: 16qZkuCBp9b
Depends on D12576
Differential Revision: https://phabricator.services.mozilla.com/D12577
--HG--
extra : moz-landing-system : lando
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
In JsPropertyProvider, if doing a property access (with a dot),
check that the results are suited for a dot notation (e.g. `data`
is, while `data-test` is not).
In case, of an element access, we can return everything.
This implies making some changes to some tests which were using
invalid dot notation access in some case, which revealed a
bug with bracket autocomplete and spaces.
So the bracket autocomplete with spaces is now also fixed, and
a test case was added for that as well.
Differential Revision: https://phabricator.services.mozilla.com/D12726
--HG--
extra : moz-landing-system : lando
We were dipatching the "connect" request manually, whereas we should be using
protocol.js specifications. It also help getting rid of another use of "form"
instead of "front"/activeTab in Target class.
MozReview-Commit-ID: IOH4mDprAVL
Depends on D12577
Differential Revision: https://phabricator.services.mozilla.com/D12578
--HG--
extra : moz-landing-system : lando
I did a dedicated patch for converting both about:debuggings as it is slightly more
complex as we have to tweak redux data, wrappers, mocks.
This patch also convert a manual "reload" request being done by about:debugging
and instead use protocol.js front to do it.
Also, I moved isLegacyTemporaryExtension to the front as it depends on accessing the form
and it should be better to keep form processing to the fronts, if possible.
MozReview-Commit-ID: 16qZkuCBp9b
Depends on D12576
Differential Revision: https://phabricator.services.mozilla.com/D12577
--HG--
extra : moz-landing-system : lando
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
Without this devtools/server/tests/unit/test_breakpoint-22.js fails in protocol.js
writeError function when trying to use console object.
MozReview-Commit-ID: JFhFboHugUh
Differential Revision: https://phabricator.services.mozilla.com/D12309
--HG--
extra : moz-landing-system : lando
This pleases clang-format and makes many of these behave better when
auto formatted. Special cases may still be marked |clang-format off| in
later commits.
Differential Revision: https://phabricator.services.mozilla.com/D12231
--HG--
extra : moz-landing-system : lando
This was only used by test and isn't much useful.
MozReview-Commit-ID: DeIimVmMOOs
Depends on D11623
Differential Revision: https://phabricator.services.mozilla.com/D11624
--HG--
extra : moz-landing-system : lando
It allows to send the event through the front rather than DebuggerClient.
MozReview-Commit-ID: H8zEwAlUWDb
Depends on D11622
Differential Revision: https://phabricator.services.mozilla.com/D11623
--HG--
extra : moz-landing-system : lando
To make $0 autocompletion work, we need to pass the current
selectedNode actor from the frontend, so we can retrieve the
object reference later.
For $_, we need the webconsole actor reference to be able
to retrieve the last input result.
Since the list of parameters of JsPropertyProviders was
getting a bit long, we transform them in an object so it's
more legible on the consumer side.
Mochitests are added for both helpers to ensure this work
as expected.
Differential Revision: https://phabricator.services.mozilla.com/D11866
--HG--
extra : moz-landing-system : lando
This was only used by test and isn't much useful.
MozReview-Commit-ID: DeIimVmMOOs
Depends on D11623
Differential Revision: https://phabricator.services.mozilla.com/D11624
--HG--
extra : moz-landing-system : lando
It allows to send the event through the front rather than DebuggerClient.
MozReview-Commit-ID: H8zEwAlUWDb
Depends on D11622
Differential Revision: https://phabricator.services.mozilla.com/D11623
--HG--
extra : moz-landing-system : lando
Front.actor custom implementation is only used from Front class and doesn't match Pool's one behavior.
Front users would expect to see the one from Pool as it inherits from it.
MozReview-Commit-ID: 8plo2K5kEWq
Differential Revision: https://phabricator.services.mozilla.com/D11614
--HG--
extra : moz-landing-system : lando
Depends on D11209
We need to take care when deleting a declaration. This means shifting the indexes of declarations which follow it in the CSS rule. To do this, we iterate over all tracked added/removed declarations and make sure to decrement their index if it is larger than the index of the deleted one.
The Rule view and specialized editors do not support inserting declarations at any other position other than at the end of the existing declarations list. For now, it is safe to assume all newly added declarations will not shift any tracked indexes. But we will need to handle this for other use cases, like the Style Editor or manual editing of element style attributes.
MozReview-Commit-ID: InrNbsNsqz6
Differential Revision: https://phabricator.services.mozilla.com/D11318
--HG--
extra : moz-landing-system : lando
When provided a number literal, JsPropertyProvider would
not return anything.
This patch solves this issue by adding an if case for those
objects.
Numerous test cases are added in test_js_property_provider to
make sure we handle this as expected and that we don't have
false positives.
Differential Revision: https://phabricator.services.mozilla.com/D11483
--HG--
extra : moz-landing-system : lando
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : cefe252618cd3a1b0e0cd5a71b056dd2b557f1a3
extra : intermediate-source : 35af79575f54f75d22e213fdac7ddd704b40807a
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : 24feb46363b5e43f35b51614d9dc6ae20ae49b65
extra : amend_source : 3c2051b98f19dc3288c59b0028db7d33c6953be3
extra : intermediate-source : 8404cc6140177a40c7086ddd4bf5d84735681048
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
Keep our old 'progressbar' as an alias for now, but unship
'progresschunk' by restricting it to UA/chrome sheets only.
Unship 'progresschunk-vertical' by removing it since it's
not used internally for anything.
This patch adds two things to JsPropertyProvider:
- when provided an input which try to access an unsafe
getter properties, the function will indicate that an
unsafe getter should be invoked, with its name.
- a new boolean argument that when set to true would
invoke any unsafe getter that might be in the expression
to be completed.
For simplicity sake, the function only warns the user
of the presence of an unsafe getter when it's the last
property of the expression:
`object.myGetter.` will return that `myGetter` should be invoked
`object.myGetter.a.b.` will not (because then, a and b could
also be getters, and it's getting complex to handle both in
the function itself as in the UI).
Tests are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D11170
--HG--
extra : moz-landing-system : lando
The use of <iframe mozbrowser> in test_saveHeapSnapshot_e10s_01.html has
implicitly depended on the "network.disable.ipc.security" pref set to
false, which is the default for desktop and not applicable for Fennec.
With the new mobile test harness, this pref needs to be set explicitly
by the test.
Differential Revision: https://phabricator.services.mozilla.com/D7786
At first, I wanted it is better to call DebuggerServer.destroy() when
`devtools.debugger.remote-enabled` will set to false. Likewise, call
DebuggerServer.init() in case of true. But, because DebuggerServer.init() is
called by various context such as RemoteDebugger, restoring is difficult after
destroying. In this patch, simply, we make avoiding to call
DebuggerServer.closeAllListener() from inside of ServerSocketConnection.
Depends on D10864
Differential Revision: https://phabricator.services.mozilla.com/D10865
--HG--
extra : moz-landing-system : lando
Yet another approach. In the previous D9889 approach, both DebuggerSerever and
SocketServerListener retain the connections duplicately, it will be possible to
be difficult for the management. In this approach, only DebuggerSerever retains
the connections, then when ServerSocketListener was removed, removes the
connections as well that were linked the ServerSocketListener.
Differential Revision: https://phabricator.services.mozilla.com/D10864
--HG--
extra : moz-landing-system : lando
shape-outside, shape-margin, shape-image-threshold have been shipped in Firefox
62. We can remove the preference.
The change in devtools/shared/css/generated/properties-db.js is generated by
"./mach devtools-css-db"
The actual shape-image CORS mode tests in file_shape_outside_CORS.html are
moved into test_shape_outside_CORS.html because we don't need the <iframe>
trick to enable the feature.
Differential Revision: https://phabricator.services.mozilla.com/D10804
--HG--
extra : moz-landing-system : lando
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : source : a19c6b3e0402d16a77185f82d9fedab83a7ca52e
extra : intermediate-source : 28a19b7290ab288a1cb2cbf6d49f905cecc9682b
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : source : a19c6b3e0402d16a77185f82d9fedab83a7ca52e
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : rebase_source : f358f1f7097eaa8cd62ae916d048a58489e9f5ff
extra : histedit_source : c44c42de02750d71e23e70fdf22d3c3a40b91d3d
For now, we keep supporting the prefixed version, since there are examples/instructions
on the Web that don't include an unprefixed value.
Differential Revision: https://phabricator.services.mozilla.com/D10451
--HG--
extra : moz-landing-system : lando
In cases where an item did not grow or shrink, devtools doesn't really have access
to any useful information about how the item might have wanted to flex.
So in this change, I'm just making sure we don't attempt to display this info at
all, because it's basically incorrect otherwise.
Depends on D10235
Differential Revision: https://phabricator.services.mozilla.com/D10236
--HG--
extra : moz-landing-system : lando
frames() timing function was removed from the spec, so we drop it.
Besides, some devtool tests are removed because they use frame(). I will
add them back by using new step function later.
Differential Revision: https://phabricator.services.mozilla.com/D9309
--HG--
extra : moz-landing-system : lando
Depends on D8722
Include the "!importat" priority flag when tracking changes to CSS declarations.
Differential Revision: https://phabricator.services.mozilla.com/D8967
--HG--
extra : moz-landing-system : lando
⚠️ **To build locally, this change series depends on the [change series](https://phabricator.services.mozilla.com/D4399) which adds the ChangesActor**.
🏋️♂️ **To test hands-on, you can download a [custom macOS build](https://queue.taskcluster.net/v1/task/HIiZcwLXTuuSYYjfwEDmmA/runs/0/artifacts/public/build/target.dmg) (updated Wed, Oct 24) which includes both change series.**
- Introduce ancestorRules getter to StyleRuleActor to get a flattened rule tree with the ancestors of the current rule;
- Introduce CSSRuleTypeName to css-logic helpers to map between CSS rule type and human-readable name;
- Log rule index position with each CSS declaration change to help differentiate between changes to rules with identical selectors at the same level of nesting.
Differential Revision: https://phabricator.services.mozilla.com/D8718
--HG--
extra : moz-landing-system : lando
The int preference profiler.sample-frequency-khz didn't make it possible
to reduce the overhead in tests, because we could have intervals bigger
than 1ms. With this change we can now do it.
Depends on D8547
Differential Revision: https://phabricator.services.mozilla.com/D8548
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Logan Smyth
yulia
Gurzau Raul
Razvan Caliman
Alexandre Poirot
Julian Descottes
Jonathan Kingston
Nicolas Chevobbe
Ryan Hunt
Oana Pop Rus
Brian Hackett
Dorel Luca
Hiroyuki Ikezoe
Yura Zenevich
Csoregi Natalia
Narcis Beleuzu
Michael Ratcliffe
Brindusan Cristian
Jason Laster
Alex Gaynor
Andrew Swan
Gabriel Luong
Daniel Varga
Bogdan Tara
Cosmin Sabou
Sebastian Hengst
vinoth
Kris Maglione
Patrick Brosset
Margareta Eliza Balazs
Mats Palmgren
arthur.iakab
Noemi Erli
Oriol Brufau
Nazım Can Altınova
Jan de Mooij
Anshul Malik
Razvan Maries
Daisuke Akatsuka
Jeff Walden
Andreea Pavel
Boris Chiou
Tom Schuster
Ciure Andrei
Coroiu Cristina
Sylvestre Ledru
Tooru Fujisawa
Benjamin Bouvier
Ehsan Akhgari
Ted Campbell
Paolo Amadini
tanhengyeow
Dave Townsend
Jim Chen
Ting-Yu Lin
Cameron McCormack
Brad Werth
Julien Wajsberg