Add package.json to devtools/client/inspector
Integration with devtools-local-toolbox:
- provides development server
- default webpack config
- landing page to select a tab
In this patch:
- bin/dev-server-js contains the inspector specific routes
- webpack/*-sham.js : inspector dependencies that had to be mocked
ideally, decoupling work should continue and the inspector client
should only ever require files that require no chrome priviledged
APIs.
- toolbox.js contains the interface with devtools-local-toolbox bootstrap
and the inspector panel initialization
- configs/development.json is the inspector config for the devtools-local-toolbox
MozReview-Commit-ID: 7YQLUlgSyDX
--HG--
extra : rebase_source : aba8fac87b66546dbb98f8f8d476cd1557c2659d
Bug 1312236 updated React to v15.3.2 which was making webconsole's mocha test fail.
An error was thrown because the path and export we do in requireHelper to make enzyme
able to call React functions was changed.
We fix the require to ReactDOM by using the react-dom.js file, and we add the similar
react-dom-server.js for ReactDOMServer functions.
Tests now run like they used to.
MozReview-Commit-ID: GXIQJPlqp4A
--HG--
extra : rebase_source : 909bde919dd4d77d8910b4dba7392283f130333a
Add a target property and show the event name (and modifiers if any) in the title.
Minor edit in GripRep to allow to pass a title as a prop.
Edit tests accordingly, and add some to test node highlighting.
MozReview-Commit-ID: JmMidejKS6m
--HG--
extra : rebase_source : 29ad4d398ad7518d752b323a6e6393cd30b18a0a
Ideally we would have used the GUID to join fields to build the compound key but because we show the uniqueId in the tree that would lead to an ugly user experience. As an
alternative we simply use e.g. db1 (default) as the uniqueId. This works as a unique key, is informative for the user and means minimal changes to tests.
MozReview-Commit-ID: I0XxTIoV33p
--HG--
extra : rebase_source : a8a9729ae639f68e849fc8239c36f451496847ad
Check that the `preview` property is not null before using it.
The bug was harmless because we catch it and return an
empty array as the properties of the grip, which is the same
when we don't have anything in the preview prop.
MozReview-Commit-ID: COU8XLATw7x
--HG--
extra : rebase_source : e3b4efbc4957efdeda760917b6b7d22ad02f64ce
On elementNodeRep, we have different outputs for tiny and short modes, and
short and long modes are the same.
Since the current long mode of textNodeRep aren't used anywhere, we can do the
same, i.e. have a really small representation for tiny mode, and then the same
rendering for short and long modes.
Modify tests to adapt them to the new rendering.
MozReview-Commit-ID: BRA7iADkn1C
--HG--
extra : rebase_source : 1e33216239ebdcde47a0f7e80e3c138a8d3335f2
Adapt tests that relied on an other length for long mode.
MozReview-Commit-ID: J00UmOa2AwJ
--HG--
extra : rebase_source : a7ff746662f006e1a132ce1e21cac3a0cbbea0e2
Add in serviceContainer highlight and unhighlight utils function so they can
be accessible in components.
Fix EvaluationResult component to pass the serviceContainer to the MessageBody.
Modify ElementNodeRep and TextNodeRep to allow passing them function properties
`onDOMNodeMouseOver` and `onDOMNodeMouseOut` that will be called respectively
on mouseOver and mouseOut.
Add a mochitest in the webconsole to make sure we indeed highlight and unhighlight
node as expected, and add tests in Reps to make sure the passed functions get called
as expected.
MozReview-Commit-ID: 8o8WM7vBfMM
--HG--
extra : rebase_source : 445f02a72b1c9859c0b034ca9e941a7f3df9f4e0
Handle the different kind of error objects.
Allow to pass a className to the objectLink component.
Add test to make sure we handle those objects as expected.
MozReview-Commit-ID: IC7ruV9odw1
--HG--
extra : rebase_source : b80c612f198af266d52ba6a56693923452a50dec
Display a longString with what is available on the grip.
Straight from the server, a longString grip has a "initial"
property, which contains the first 10000 chars of the string.
The grip can also contains a "fullText" property that should
be set when the user want to display the full text of the string.
For example, in the DOM Panel, it would be when the user click on
the expand arrow.
The fullText needs to be computed with the result of the
LongStringClient.substring function, but it's not the responsability
of the Reps to do such thing.
In rep-utils, we extract the logic that replace non-printable
characters in its own function and export it, so we can use it outside
the cropString function.
Add some test to make sure LongString are displayed as expected in the
several modes.
MozReview-Commit-ID: 3P9fPBixm2v
--HG--
extra : rebase_source : 87ed610cb6d2e142728f0df9d35f1dd7a4748d18
Julian Descottes
Towkir Ahmed
Wes Kocher
Ruturaj K. Vartak
Brian Grinstead
Nicolas Chevobbe
Tom Tromey
Jarda Snajdr
Michael Ratcliffe
Carsten "Tomcat" Book
Lin Clark
djmdev
Astley Chen
Gabriel Luong
Dalimil Hajek
Tim Nguyen
Tooru Fujisawa
Phil Ringnalda
James Long