This patch turns property access that would result in
Syntax error (e.g. `x.data-test`) into element access
(e.g. `x["data-test"]`) when accepting a completion
value in the console input.
In order to do that, we use Reflect to parse a custom
expression where we try to define the property the user
is going to accept. If this throws, this means we need to
modify the input into an element access.
A test is added to make sure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D8952
--HG--
extra : moz-landing-system : lando
The code we had to jump to the style-editor when a rule-view source link is clicked did
not make any distinction between multiple inline stylesheets. If you had many of them,
they would all have the same url (i.e. the url of the document, because they are
inline). And we were matching stylesheets in the style-editor by url, so we would
always select the first inline stylesheet.
This change makes use of the fact that the style-editor's selectStyleSheet function
also accept a StyleSheetFront object. When passing this object, there can be no
confusion, because they're all different.
Now, I'm only doing this for inlin stylesheets because other stylesheets have unique
urls and it's important to preserve the previous logic since source-maps may also be
involved.
I'm taking this opportunity to re-enable browser_rules_style-editor-link.js which had
been disabled a long time ago, and removing a part that just doesn't work anymore at
all apparently.
Differential Revision: https://phabricator.services.mozilla.com/D9093
--HG--
extra : moz-landing-system : lando
This preparatory work will be necessary to enable CSP for the new about
debugging.
Differential Revision: https://phabricator.services.mozilla.com/D8854
--HG--
extra : moz-landing-system : lando
The current iteration of the Fonts panel requires an instance of the Rules view
in order to get access to the element's rules.
In 2-pane mode, when the Fonts panel is the default (last used panel), the Rules
view is not yet instantiated. To guard against this, the Fonts panel makes a call
to ensure an instance of the Rules view is created (and with it a CSSRuleView object).
For some reason, the pageStyle wasn't immediately assigned to the CSSRuleView in
the constructor. The constructor signature shows that pageStyle can be passed in as a
param, but this never happens. There's only one usage of `new CSSRuleView()`.
The pageStyle exist on the inspector instance passed in to the CSSRuleView.
This patch ensures that the CSSRuleView makes use of the PageStyleFront instance
from the inspector and removes the unused param from the constructor.
Perhaps it's better for the Fonts panel to manage its own ElementStyle instance to
get access to the element's selected rules. But in the interest of time, since the
merge date is soon, I'd rather have this fix in quikcly now and keep the dependency
to a Rules view instance with the promise to revisit the Fonts panel architecture and
remove this dependency during the Firefox 65 Nightly cycle.
Differential Revision: https://phabricator.services.mozilla.com/D9002
--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
--HG--
extra : moz-landing-system : lando
Before this patch, in developer console, enabling persist log, message displayed "Navigated to" ..something was not distinguishable from console.log messages. Now specific class for navigation marker is added.
Differential Revision: https://phabricator.services.mozilla.com/D7040
--HG--
extra : moz-landing-system : lando
This patches solves 2 issues:
- it doesn't return any result when the user is trying to
perform a variable, function or class declaration (e.g.
var d).
- js-property-provider used to compute the last statement
by only looking for space or ; chars. But there are a lot
of cases (basically each time using an operator), where we
should return results and we weren't.
Test cases are added to cover those fixes.
Differential Revision: https://phabricator.services.mozilla.com/D8968
--HG--
extra : moz-landing-system : lando
On the server, when looking for a flex container for a node, we were bailing
out if the displayType of the node was null. It was null for pseudo-elements.
This value was returned by the displayType getter in the NodeActor class.
Now, the reason for this dates to 4 years ago in bug 1139937 where trying to
get the display style of a pseudo-element was done in a way to failed. So we
just decided to return null at that point. It doesn't fail anymore, we're
able to return, say, "block" if a pseudo-element has a display:block style.
So I've removed the checks that returned null and that fixed the issue here.
The other part of the fix that was need is in the FlexItemActor class on the
server too. This class can be created for a pseudo-element too.
It accesses element.style without checking if that property exists. However it
does not exist for pseudo-elements. So we needed to add a check for that.
It's not a problem to just skip it in this case because pseudo-elements can't
have inline styles.
Differential Revision: https://phabricator.services.mozilla.com/D8873
--HG--
extra : moz-landing-system : lando
Depends on D8334.
In this changeset we also change the way we are reading the preferences
in adb-addon.js to avoid caching the value of the preference the first
time the module is loaded.
This allows the module to follow updates of said preferences without
having to restart Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D8335
--HG--
extra : moz-landing-system : lando
Maybe we want to land the simplest solution for now and discuss
quickly how to style the message to reduce confusion in a follow up?
Differential Revision: https://phabricator.services.mozilla.com/D8334
--HG--
extra : moz-landing-system : lando
Depends on D8334.
In this changeset we also change the way we are reading the preferences
in adb-addon.js to avoid caching the value of the preference the first
time the module is loaded.
This allows the module to follow updates of said preferences without
having to restart Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D8335
--HG--
extra : moz-landing-system : lando
Maybe we want to land the simplest solution for now and discuss
quickly how to style the message to reduce confusion in a follow up?
Differential Revision: https://phabricator.services.mozilla.com/D8334
--HG--
extra : moz-landing-system : lando
For now, the options panel was calling `attach` to know if the javascript was disabled
on the debugged document. But this property is already cached during the `attach`
request done by the toolbox.
MozReview-Commit-ID: JcDT6vxCUzN
Depends on D8851
Differential Revision: https://phabricator.services.mozilla.com/D8852
--HG--
extra : moz-landing-system : lando
A function was missing in the serviceContainer stub,
and the console.trace with params test needed a
Provider wrapper to work with the latest changes made
to the ObjectInspector.
Differential Revision: https://phabricator.services.mozilla.com/D8861
--HG--
extra : moz-landing-system : lando
In this patch, I converted the call sites where there was an obvious target. I left out
those where there wasn't one... Should these be converted as well?
Depends on D8369
Differential Revision: https://phabricator.services.mozilla.com/D8374
--HG--
extra : moz-landing-system : lando
This is part 1 of bug 1497545, and covers the most difficult case, which is migrating
attachURL to something a bit more modern and easier to read. The goal is to make our tests more
consistant with our code base now, and keep these tests maintainable.
UPDATE: I will split this up, as it is too large to review in one pass
Differential Revision: https://phabricator.services.mozilla.com/D8369
--HG--
extra : moz-landing-system : lando
This patch moves the parserService from the toolbox,
which isn't accessible in the case of the Browser Console,
to the console itself.
A lightweight test is added to ensure top-level await is
supported in the browser console.
Differential Revision: https://phabricator.services.mozilla.com/D8816
--HG--
extra : moz-landing-system : lando
Added new getters to the ADB scanner so our runtime objects have now the information we need.
Note that the UX of the devices in this patch doesn't still match what we had in the mockups (icons don't match, and we also need a circle with a tick), but since we have another bug to handle the CSS in the Sidebar, we can always adapt it there. The information needed to display what is shown in the mockups should be passed in this patch –if I miss anything, give me a shout!
Differential Revision: https://phabricator.services.mozilla.com/D7705
--HG--
extra : moz-landing-system : lando
This is a refactor of the components used in the sidebar. TL;DR: sidebar items now use the composition approach outlined here https://reactjs.org/docs/composition-vs-inheritance.html
Before we had a container `Sidebar` component, which in turn had `SidebarItem` components inside. The issue was that depending on what item is inside, the information and UX displayed is different. Before this patch, we had an optional commponent, `DeviceSidebarItemAction` –which was featuring a "Connect" button, and was only rendered in the runtime sidebar items. However, we now need to display even more info, so continue to pass optional components to `SidebarItem` was tricky.
What this patch does is to preserve `SidebarItem` and treat is a generic container of more specific content. This is passed via the `children` prop, which React automatically maps to the DOM content that we pass to that component (this is the same concept as slots in Web Components / Vue). `SidebarItem` now only contains the logic to select items in the sidebar and render them in `<li>` elements. Two new components, `SidebarFixedItem` (for our "static" pages) and `SidebarDeviceItem` are now the ones instancing `SidebarItem` with their specific contents.
Differential Revision: https://phabricator.services.mozilla.com/D7704
--HG--
extra : moz-landing-system : lando
Depends on D8334.
In this changeset we also change the way we are reading the preferences
in adb-addon.js to avoid caching the value of the preference the first
time the module is loaded.
This allows the module to follow updates of said preferences without
having to restart Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D8335
--HG--
extra : moz-landing-system : lando
Maybe we want to land the simplest solution for now and discuss
quickly how to style the message to reduce confusion in a follow up?
Differential Revision: https://phabricator.services.mozilla.com/D8334
--HG--
extra : moz-landing-system : lando
If push the ctrl+t, browser will open the new tab. In this case,
the XUL popup panel doesn't hide automatically(autohide=false).
As the result of it, the popup menu will be displayed in the new tab
content. So this patch will hide the popup when receiving the ctr+t
shortcut in the MenuButton.
Differential Revision: https://phabricator.services.mozilla.com/D8809
--HG--
extra : moz-landing-system : lando
If we displayed the devtools across the second screen, the Screen.availLeft
might be not zero. I.e., Screen.availLeft point to second screen's left.
The HTMLTooltip does't consider this case, so this patch will change the
viewpor's left and right position if the left of anchor element is bigger than
screen.right.
Differential Revision: https://phabricator.services.mozilla.com/D8183
--HG--
extra : moz-landing-system : lando
JsTerm's focus function was called in clearOutput, which
we call when navigating to a new page (if Persist Logs is
not checked).
This means that we were forcing the JsTerm to be focused
each time the user navigated while having the console open.
This behavior, can be annoying, or at worst, if you're
debugging a focus issue in your content page, completely maddening.
The fix is striaghtforward: do not call focus in clearOutput.
A test is added to make sure we don't regress this.
Differential Revision: https://phabricator.services.mozilla.com/D8701
--HG--
extra : moz-landing-system : lando
* browser_addons_debug_webextension_popup: It looks like frame-update events are now fired earlier.
I had to move the listener to an earlier step in order to make it work.
* helper_disable_cache + toolbox.js: this test wasn't correctly listening for reconfigure request's end.
Not clear how this test was passing before without high rate of intermittent...
* test_webextension-addon-debugging-connect.html: We can no longer listen for frame-update *before* the target object is created.
(because we now need a TabTarget object or the TargetFront and not just the DebuggerClient)
* Fix reload request in shadereditor which may still be pending after test ends.
MozReview-Commit-ID: 49qvWSCn6nq
Depends on D8066
Differential Revision: https://phabricator.services.mozilla.com/D7460
--HG--
extra : moz-landing-system : lando
* debugger-controller and events.js are special and require to support two cases because this is
the only production codepath that can have a TabTarget or a WorkerTarget.
Thus, leading to either TargetFront or WorkerClient on target.activeTab.
* webide.js doesn't need to listen for tabNavigated, this is redundant with tabListChanged.
* application's initializer. In case you are wondering this code can't be spawn against a WorkerTarget.
The application panel doesn't work in worker toolboxes.
* The code modified in target is in TabTarget, so we don't have to support the WorkerClient case, we always have a TargetFront here.
* I tried to update the doc file the best I can but this all feel outdated.
MozReview-Commit-ID: 2hGchebfIub
Depends on D7458
Differential Revision: https://phabricator.services.mozilla.com/D7459
--HG--
extra : moz-landing-system : lando
TabClient appears to be a client for any actor that inherits from browsing context target actor.
So let it be a front for that.
MozReview-Commit-ID: KmpClxJ53N7
Depends on D7457
Differential Revision: https://phabricator.services.mozilla.com/D7458
--HG--
extra : moz-landing-system : lando
Added new getters to the ADB scanner so our runtime objects have now the information we need.
Note that the UX of the devices in this patch doesn't still match what we had in the mockups (icons don't match, and we also need a circle with a tick), but since we have another bug to handle the CSS in the Sidebar, we can always adapt it there. The information needed to display what is shown in the mockups should be passed in this patch –if I miss anything, give me a shout!
Differential Revision: https://phabricator.services.mozilla.com/D7705
--HG--
extra : moz-landing-system : lando
This is a refactor of the components used in the sidebar. TL;DR: sidebar items now use the composition approach outlined here https://reactjs.org/docs/composition-vs-inheritance.html
Before we had a container `Sidebar` component, which in turn had `SidebarItem` components inside. The issue was that depending on what item is inside, the information and UX displayed is different. Before this patch, we had an optional commponent, `DeviceSidebarItemAction` –which was featuring a "Connect" button, and was only rendered in the runtime sidebar items. However, we now need to display even more info, so continue to pass optional components to `SidebarItem` was tricky.
What this patch does is to preserve `SidebarItem` and treat is a generic container of more specific content. This is passed via the `children` prop, which React automatically maps to the DOM content that we pass to that component (this is the same concept as slots in Web Components / Vue). `SidebarItem` now only contains the logic to select items in the sidebar and render them in `<li>` elements. Two new components, `SidebarFixedItem` (for our "static" pages) and `SidebarDeviceItem` are now the ones instancing `SidebarItem` with their specific contents.
Differential Revision: https://phabricator.services.mozilla.com/D7704
--HG--
extra : moz-landing-system : lando
Remove the floating scrollbar implementation used on Linux now that CSS scrollbar-color
landed for Linux. Also force scrollbar-color for the DevTools light theme on Linux, to
avoid visual conflicts with dark GTK themes.
Differential Revision: https://phabricator.services.mozilla.com/D7858
--HG--
extra : moz-landing-system : lando
- Made the border for the final size thicker
- Made the delta area more transparent
- Removed the arrow-head pattern for the delta area
- Added a thin horizontal arrow instead
- Removed the background circle around the lock icon
- Added a non-blurry shadow area around it instead
The mockup also called for adding a new label for "grow".
I did not implement this yet, because this will require more
work that can be done in a separate bug. We also need to
decide what happens if there isn't enough room to display
it.
Differential Revision: https://phabricator.services.mozilla.com/D8520
--HG--
extra : moz-landing-system : lando
Use wake lock to keep screen when device is attached from debugger.
Differential Revision: https://phabricator.services.mozilla.com/D7161
--HG--
extra : rebase_source : 4f204b8ad598cca981987b8661d67aecde3de818
- Made the border for the final size thicker
- Made the delta area more transparent
- Removed the arrow-head pattern for the delta area
- Added a thin horizontal arrow instead
- Removed the background circle around the lock icon
- Added a non-blurry shadow area around it instead
The mockup also called for adding a new label for "grow".
I did not implement this yet, because this will require more
work that can be done in a separate bug. We also need to
decide what happens if there isn't enough room to display
it.
Differential Revision: https://phabricator.services.mozilla.com/D8520
--HG--
extra : moz-landing-system : lando
- Added AutoRefreshHighlighter flag to AutoRefreshHighlighter. This ensures that getQuads() ignores the zoom factor.
Differential Revision: https://phabricator.services.mozilla.com/D7599
--HG--
extra : moz-landing-system : lando
Fixes the 3 places where long element Reps can appear:
- as a accordion header as "flex item of div..."
- as a flex item in the list of items for a container
- as a flex container
To fix this, I added text-overflow:ellipsis in a few places and made sure the Rep
was not pushing other things too far behind the viewport.
I also made the layout sidebar overflow-x:hidden, because it doesn't need to
scroll sideways (if the sidebar is too thin, then the box-model diagram might
overflow, but it has its own horizontal scrollbar).
Finally, I removed the inspector select icon next to the Flex Container Rep
because usually the element is already selected anyway. If it's not, then you
can use the back arrow to go back to the container.
Differential Revision: https://phabricator.services.mozilla.com/D8364
--HG--
extra : moz-landing-system : lando
