searching for reviewer(pbro)
820aca345d9e018e23d3273ff0cb7d1b7883bff3: Bug 1578242 - Make the inspector use the TargetList. r=gl,pbro
Alexandre Poirot <poirot.alex@gmail.com> - Mon, 18 Nov 2019 15:06:02 +0000 - rev 502444
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1578242 - Make the inspector use the TargetList. r=gl,pbro Differential Revision: https://phabricator.services.mozilla.com/D48859
b8a3793ecceb864e30b0c7d060dc9397770b1d9e: Bug 1593944 - Test to ensure inactive CSS state does not linger when dependencies change. r=miker,pbro
Razvan Caliman <rcaliman@mozilla.com> - Wed, 13 Nov 2019 13:56:50 +0000 - rev 501739
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1593944 - Test to ensure inactive CSS state does not linger when dependencies change. r=miker,pbro Depends on D52560 - Adds a test to check that the steps for [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944) no longer cause an issue. - Introduces a new `updateDeclaration()` helper in `devtools/client/inspector/rules/test/shared.js` to simplify updating property names and values in one step. - Updates `toggleDeclaration()` to remove unused `inspector` parameter; updates existing tests. Differential Revision: https://phabricator.services.mozilla.com/D52561
47a58584b81390485c7530b1eef7d59b2d6c32b2: Bug 1593944 - Emit event with StyleRuleActor as argument when its underlying CSS rule is updated. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Wed, 13 Nov 2019 14:04:37 +0000 - rev 501738
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1593944 - Emit event with StyleRuleActor as argument when its underlying CSS rule is updated. r=pbro The fix for [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) created a situation in the [`Rule.onDeclarationsChanged()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/inspector/rules/models/rule.js#869-887) whereby the `isUsed` state of client-side declarations was made to point to a fixed `isUsed` state received from the server, thus losing sync with the latest state of the `StyleRuleActor`. Until another "declarations-update" event was fired from the `StyleRuleActor`, the rule's declarations' `isUsed` flag would point to the state with which they were overwritten on the last event handler call. As a reminder, the root cause of [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) was the inability force a "refresh" of the `StyleRuleFront` so it picked-up the latest `isUsed` state for its declarations when they depend on other declarations from other rules (ex: `justify-content: center` depends on `display:flex`). Therefore, the "declarations-updated" event was introduced with a payload of changed declarations to overwrite the client-side ones. It was convoluted, but it worked. However, while investigating the cause of this newer bug [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944), I discovered an unusual but perhaps expected side-effect: when dispatching an event over the protocol with a payload of the `StyleRuleActor`, its corresponding `StyleRuleFront` on the client would "refresh" automatically (meaning that, looking up state on the previous front reference would point to the latest state from the actor) . The client doesn't even need to use this payload to replace its previous front reference. Surprisingly, the client doesn't even need to explicitly listen to the event which carries the `StyleRuleActor`/`StyleRuleFront` reference. So long as a previous reference of the front exists on the client, it will point to the updated state of the actor. I haven't been able to identify whether this is a known and expected behavior, so I'm pinging @jdescottes and @ochameau to weigh in on the validity of these findings. Relying on this behavior, the fix for both [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) and [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) involves simply emitting an event, "rule-updated", with the `StyleRuleActor` instance as payload whenever its internal state changes meaningfully so the corresponding front updates. The client will pick-up the latest `isUsed` state of declarations from its reference to the `StyleRuleFront`. --- Another way to check this behavior and hypothesis is to do the following: - In [`StyleRuleActor.setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1704) replace `return this` with `return null`; (this will no longer return the `StyleRuleActor` over the protocol; it's not explicitly used on the client anyway). - In the spec, replace the [`setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/shared/specs/styles.js#222) return value with `RetVal("nullable:domstylerule")` so the protocol doesn't throw an error when getting the `null` from the actor. - Make a build. - Then, open the Inspector -> Rules View and change the value of a valid declaration, say: `display: block`, to something invalid, like `display: booo`. Notice that the declaration is no longer marked invalid with a warning sign. That's because the declaration's [`isValid`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1447) flag is set on the actor but it no longer syncs with the client which uses the corresponding front to render the declaration after the change. Not returning the `StyleRuleActor` over the protocol breaks this sync actor-front sync. Differential Revision: https://phabricator.services.mozilla.com/D52560
27157ea1dd6023268ea5f736ee0fd70697620d5d: Bug 1593921 - Use eslint-disable-next-line to disable complexity checks in DevTools r=pbro
Julian Descottes <jdescottes@mozilla.com> - Tue, 05 Nov 2019 14:29:04 +0000 - rev 501042
Push 114167 by csabou@mozilla.com at Fri, 08 Nov 2019 00:35:25 +0000
Bug 1593921 - Use eslint-disable-next-line to disable complexity checks in DevTools r=pbro Using next-line is less error prone for refactorings than wrapping methods with enable/disable blocks. Differential Revision: https://phabricator.services.mozilla.com/D51782
ee250b40876eba948eb7f21bde87701c53f597fa: Bug 1588773 - Move css-selector.js helpers back to DevTools css-logic.js r=pbro
Julian Descottes <jdescottes@mozilla.com> - Mon, 28 Oct 2019 09:11:02 +0000 - rev 499570
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1588773 - Move css-selector.js helpers back to DevTools css-logic.js r=pbro Depends on D49303 Some methods from css-logic were extracted from the devtools codebase to be used by context-menu files. This was only needed in order to compute the css-selectors for Inspect Element. If we use ContentDOMReference instead, those helpers can move back in the devtools codebase (leaving them in css-selector.js fails the all-files-referenced test for some reason as well) Differential Revision: https://phabricator.services.mozilla.com/D49330
a69208bb8c1a98d14b87a76f56c37863544d9bc8: Bug 1588773 - Use ContentDOMReference for context menu Inspect Element r=mconley,pbro
Julian Descottes <jdescottes@mozilla.com> - Mon, 28 Oct 2019 09:10:29 +0000 - rev 499569
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1588773 - Use ContentDOMReference for context menu Inspect Element r=mconley,pbro Depends on D49941 Using ContentDOMReference instead of creating an array of selectors makes inspect element more stable in case the page is modified between after the contextmenu opens. It will also make the feature easier to make fission compatible Differential Revision: https://phabricator.services.mozilla.com/D49303
fe4cd6e7034f742b6cd34c27cca3fe1c070a70c3: Bug 1588367 - Convert all relevant uses of float: right/left to logical properties on devtools/ r=pbro
Itiel <itiel_yn8@walla.com> - Mon, 28 Oct 2019 18:32:29 +0000 - rev 499480
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1588367 - Convert all relevant uses of float: right/left to logical properties on devtools/ r=pbro Depends on D49087 Differential Revision: https://phabricator.services.mozilla.com/D49207
85def5e9462ee92ba2f5e8ee68494dd7f37d626d: Bug 1591360 - Remove devtools/client/framework/sidebar.js. r=pbro.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Fri, 25 Oct 2019 12:39:40 +0000 - rev 499398
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1591360 - Remove devtools/client/framework/sidebar.js. r=pbro. It was only used by scratchpad which is removed in Bug 1519103. Differential Revision: https://phabricator.services.mozilla.com/D50586
f3e2042c2deb43a1c0788e5799660b39652a81c2: Bug 1550804 - Add color scheme simulation to the inspector. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Fri, 25 Oct 2019 19:28:02 +0000 - rev 499301
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1550804 - Add color scheme simulation to the inspector. r=pbro This adds a color scheme simulation toggle button in the rules view, which will toggle between 4 different states: default, dark, light, and no-preference. This feature is currently hidden away under a preference: devtools.inspector.color-scheme-simulation.enabled The final UI/UX still needs to be figured out, however, this initial step is to land the ability to prototype this feature. Differential Revision: https://phabricator.services.mozilla.com/D49833
5eb5f44dcf96cedbfeef132741fffc41dc329756: Bug 1550804 - Add color scheme simulation to the inspector. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Thu, 24 Oct 2019 20:39:00 +0000 - rev 499160
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1550804 - Add color scheme simulation to the inspector. r=pbro This adds a color scheme simulation toggle button in the rules view, which will toggle between 4 different states: default, dark, light, and no-preference. This feature is currently hidden away under a preference: devtools.inspector.color-scheme-simulation.enabled The final UI/UX still needs to be figured out, however, this initial step is to land the ability to prototype this feature. Differential Revision: https://phabricator.services.mozilla.com/D49833
f3fee3ded743561f3d60d7cc2c60f2e90ab75bc1: Bug 1550804 - Add color scheme simulation to the inspector. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Thu, 24 Oct 2019 17:23:18 +0000 - rev 499138
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1550804 - Add color scheme simulation to the inspector. r=pbro This adds a color scheme simulation toggle button in the rules view, which will toggle between 4 different states: default, dark, light, and no-preference. This feature is currently hidden away under a preference: devtools.inspector.color-scheme-simulation.enabled The final UI/UX still needs to be figured out, however, this initial step is to land the ability to prototype this feature. Differential Revision: https://phabricator.services.mozilla.com/D49833
4c71960337b5cafae81f16e23e5c5c8699a695a8: Bug 1589858: Add a test whether the rule view is available or not when plural styles which are defined in media query block are set for visited link. r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 23 Oct 2019 11:20:28 +0000 - rev 498679
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1589858: Add a test whether the rule view is available or not when plural styles which are defined in media query block are set for visited link. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D50156
02943868eb284ccb83c6041d21da1e50617fc18a: Bug 1589858: Guard from passing media rules to InspectorUtils.getSelectorCount(). r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 23 Oct 2019 09:45:41 +0000 - rev 498678
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1589858: Guard from passing media rules to InspectorUtils.getSelectorCount(). r=pbro Differential Revision: https://phabricator.services.mozilla.com/D50155
30190859b9f5abafad52151a7bae926a5d988b4b: Bug 1588728 - Add a check for this._highlightedNodeFront in _hideBoxModel. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Fri, 18 Oct 2019 18:43:49 +0000 - rev 498249
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1588728 - Add a check for this._highlightedNodeFront in _hideBoxModel. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D49632
abfee71f01b0122064a93c0f3c8cf56b887573fd: Bug 1583654 - Use the subgridToParentMap to check that the node was previously a subgrid. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Fri, 18 Oct 2019 17:57:09 +0000 - rev 498244
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1583654 - Use the subgridToParentMap to check that the node was previously a subgrid. r=pbro The previous condition didn't fully check that the grid node was previously a subgrid. So, we run into a scenario where we refresh the page and a "display-change" event is hit after a new root is loaded, and the grid highlighter is restored and hidden because the check will pass as long as the node is a grid container. Differential Revision: https://phabricator.services.mozilla.com/D49659
3eec673dbb60bff7fd8f4877103d953963317fe5: Bug 1577783 - Use inspectorFront's getNodeFrontFromNodeGrip function in WebConsole's openNodeInInspector. r=pbro,rcaliman.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Fri, 18 Oct 2019 09:07:42 +0000 - rev 498154
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1577783 - Use inspectorFront's getNodeFrontFromNodeGrip function in WebConsole's openNodeInInspector. r=pbro,rcaliman. We retrieve the right NodeFront from a given grip, which we can then tell the inspector panel to select. Differential Revision: https://phabricator.services.mozilla.com/D48810
045d50e021e41f102b08eef67ab1352db67ff027: Bug 1587701 - Use toolbox's getNodeFrontFromNodeGrip in highlight method. r=pbro.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Fri, 18 Oct 2019 09:07:25 +0000 - rev 498153
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1587701 - Use toolbox's getNodeFrontFromNodeGrip in highlight method. r=pbro. This allow us to retrieve the appropriate nodeFront from a grip, and thus the right highlighterFront to highlight a given element. We also need to cache the highlighter front used for the current highlight, as we need to use the same front for unhighlighting, and this saves us a few server round-trip to get the right front. Differential Revision: https://phabricator.services.mozilla.com/D48809
ba7304bbc693865f655b9fb4c4196fdda44192b9: Bug 1586201 - Add a function to get a nodeFront from a ContentDomReference. r=pbro,jdescottes.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Fri, 18 Oct 2019 09:07:05 +0000 - rev 498152
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1586201 - Add a function to get a nodeFront from a ContentDomReference. r=pbro,jdescottes. A function is added on the walker actor that creates a NodeFront from a ContentDomReference, e.g. an object containing a browsingContextId and a unique DOM element identifier. A trait is added on the walker actor since the ContentDomReference API was only added in Firefox 69. We then add a function on the toolbox that can return a NodeFront from a element grip. Differential Revision: https://phabricator.services.mozilla.com/D48808
1177ff81eab7605c5aba6af677257e4705b2e6f4: Bug 1586201 - Include ContentDomReference in Node grips. r=pbro.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Fri, 18 Oct 2019 09:06:27 +0000 - rev 498151
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1586201 - Include ContentDomReference in Node grips. r=pbro. This will allow us to retrieve the appropriate inspector (and thus walker, highlighter, ...) for a given element later, potentially from a different DebuggerServer. Differential Revision: https://phabricator.services.mozilla.com/D48807
e7bd0696e0c8c7b1ead41dca8df43e374f1e18f6: Bug 1581850 - Ensure target elements are highlighted when hovering selectors in DevTools Style Editor. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Tue, 15 Oct 2019 13:24:21 +0000 - rev 497667
Push 114154 by btara@mozilla.com at Thu, 17 Oct 2019 09:58:40 +0000
Bug 1581850 - Ensure target elements are highlighted when hovering selectors in DevTools Style Editor. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D46155
170116a535d6867cdd263ba34b2637449ed13f07: Bug 1584243: Wait until the link has the visited state. r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Tue, 15 Oct 2019 07:43:33 +0000 - rev 497586
Push 114154 by btara@mozilla.com at Thu, 17 Oct 2019 09:58:40 +0000
Bug 1584243: Wait until the link has the visited state. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D49225
cbf93a9af5026f51e23069851ed5953b67be78f4: Bug 1583117 - Markup view is blank if an error is thrown gathering event listeners r=pbro
Michael Ratcliffe <mratcliffe@mozilla.com> - Mon, 14 Oct 2019 12:23:13 +0000 - rev 497498
Push 114152 by dvarga@mozilla.com at Tue, 15 Oct 2019 11:14:34 +0000
Bug 1583117 - Markup view is blank if an error is thrown gathering event listeners r=pbro Differential Revision: https://phabricator.services.mozilla.com/D49134
4720725e96e99f8ca5b424313818df188b341595: Bug 1572651 - (Part 3) Add option for highlighters to get node position without scroll offsets. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Thu, 10 Oct 2019 21:51:43 +0000 - rev 497478
Push 114152 by dvarga@mozilla.com at Tue, 15 Oct 2019 11:14:34 +0000
Bug 1572651 - (Part 3) Add option for highlighters to get node position without scroll offsets. r=pbro Depends on D47092 Given that the highlighter rendering surface is sized to the viewport of the inspected page (as opposed to the whole document), we need a way to ignore scroll offsets when getting data about the node position so the highlighter doesn't get drawn off-screen. Differential Revision: https://phabricator.services.mozilla.com/D47094
e00f7651b6708a21264cf5917d2282176167e9a1: Bug 1572651 - (Part 2) Split BoxModelHighlighter into observer and renderer parts. r=pbro,jdescottes
Razvan Caliman <rcaliman@mozilla.com> - Fri, 11 Oct 2019 12:39:42 +0000 - rev 497477
Push 114152 by dvarga@mozilla.com at Tue, 15 Oct 2019 11:14:34 +0000
Bug 1572651 - (Part 2) Split BoxModelHighlighter into observer and renderer parts. r=pbro,jdescottes NOTE: To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter` Adding Julian as reviewer to check the sanity of the communication system (see `BoxModelHiglighterObserver` constructor and `BoxModelHighlighterRenderer.setMessageManager()`, `BoxModelHighlighterRenderer.onMessage()`, `BoxModelHighlighterRenderer.postMessage()`) and Patrick for the overall highlighter behavior which is mostly a clean split of the existing [`BoxModelHighlighter`](https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/devtools/server/actors/highlighters/box-model.js)). --- Depends on D47091 ## Preamble This patch looks more frightening than it actually is. Let me explain: The vast majority of the code in `box-model-highlighter-observer.js` and `box-model-highlighter-renderer.js` is a clean split of the code existing in `box-model-highlighter.js` into distinct parts which handle the node measurement (observer) and the drawing the highlighter (renderer). I kept the method names identical to help in matching them up with their original sources. There was no simple way chunk this without confusing the daylight out of you so I decided to co-locate all changes so it's easier to track and reference methods. I will detail below the important differences. ## Overview: The box model highlighter is split into two distinct parts: - an observer which monitors the node's position - a renderer which draws the highlighter on top of the node The renderer always lives in the parent process (browser window) and overlays an iframe with the highlighter markup: - either over the content if highlighting in the context of the content toolbox - or over the whole browser UI if highlighting in the context of the browser toolbox When in the context of the browser toolbox (i.e. highlighting the browser UI), both observer and renderer live in the parent process. Communication is done by direct calls. When in the context of the content toolbox (i.e. highlighting the page content), the observer lives in content process (so it can measure the node) while the renderer lives in the parent process. Communication is done by message passing via `MessageManager` (soon to be deprecated and replaced with JSWindowActor API) ## Notable differences after the split - the observer checks whether it is in the content process (aka child process) and sets up the highlighter in the parent process by using [`setupInParent()`](https://docs.firefox-dev.tools/backend/actor-e10s-handling.html) and establishes a communication system to it via message manager. If the observer is in the parent process (browser toolbox scenario), the renderer is setup directly via its constructor and no additional communication system is required. - whenever the node quads change (as determined by the untouched existing base class `auto-refresh.js`), the observer gathers the data about the node position and sends it over to the renderer. This happens in the `BoxModelHighlighterObserver._update()` (corresponding to the [`_update()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#361-383)). - the renderer expects its `render()` method to be called with the necessary node position information whenever it should update the highlighter. It is the entry point which then calls all the DOM manipulation methods copied over from the existing box model highlighter. - the only notable change in DOM manipulation methods is in `BoxModelHighlighterRenderer._updateBoxModel()` (corresponding to [`updateBoxModel()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#504-560)) where the `_nodeNeedsHighlighting()` is kept on the observer part and the canvas zoom adjustment is removed (`this.markup.scaleRootElement(this.currentNode, rootId)`) because the canvas is no longer influenced by the page zoom (the canvas lives in the browser window, not the content window) Differential Revision: https://phabricator.services.mozilla.com/D47092
b1d22c68b66d0ae5d1337e46adf387566d548298: Bug 1572651 - (Part 1) Add highlighter renderer base class r=jdescottes,pbro,bgrins
Razvan Caliman <rcaliman@mozilla.com> - Thu, 10 Oct 2019 21:51:42 +0000 - rev 497476
Push 114152 by dvarga@mozilla.com at Tue, 15 Oct 2019 11:14:34 +0000
Bug 1572651 - (Part 1) Add highlighter renderer base class r=jdescottes,pbro,bgrins **Update October 8** To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter` --- Adding Julian as reviewer to check the sanity of the communication system and Patrick for the overall highlighter behavior. --- This patch adds a base class for the renderer part of highlighters which is set up on the parent process in the browser window. This is used by the `BoxModelHighlighterRender` introduced by D47092 `HighlighterRenderer.init()` will create an HTML iframe and inject it to the appropriate position in the browser window in order to serve as a rendering surface for highlighters of the inspected page content (content toolbox) or the browser UI (browser toolbox). A host iframe is used until [Bug 1492582](https://bugzilla.mozilla.org/show_bug.cgi?id=1492582) is fixed because the browser window is XUL and does not support the anonymous canvas frame used by existing highlighters. The primary use case of `HighlighterRenderer` is as a base class for renderers which live in a separate process than the observers. This happens with highlighters for the content toolbox. Therefore, it provides methods to setup a communication system (via MessageManager for now) whereby the observer can send messages to the renderer and vice-versa: `setMessageManager()`, `postMessage()` and `onMessage()`. I used the existing code from [`AccessibilityParent`](https://searchfox.org/mozilla-central/source/devtools/server/actors/accessibility/accessibility-parent.js) as a reference for this. Classes that extend HighlighterRenderer must implement: - a typeName representing the highlighter type; used to differentiate between other types of messages when the Message Manager is used; - a _buildMarkup() method to generate the highlighter markup; - a `render()` method to update the highlighter markup when given new information about the observed node. NOTE: A temporary pink outline is set on the highlighter surface as a quick visual check to show its extent depending on context: browser toolbox or content toolbox. This will be removed before landing. Differential Revision: https://phabricator.services.mozilla.com/D47091
71db1896c4593707d9965954bfaaf370e0349bd9: Bug 1572651 - (Part 3) Add option for highlighters to get node position without scroll offsets. r=pbro
Razvan Caliman <rcaliman@mozilla.com> - Thu, 10 Oct 2019 14:15:03 +0000 - rev 497110
Push 114148 by shindli@mozilla.com at Mon, 14 Oct 2019 10:49:50 +0000
Bug 1572651 - (Part 3) Add option for highlighters to get node position without scroll offsets. r=pbro Depends on D47092 Given that the highlighter rendering surface is sized to the viewport of the inspected page (as opposed to the whole document), we need a way to ignore scroll offsets when getting data about the node position so the highlighter doesn't get drawn off-screen. Differential Revision: https://phabricator.services.mozilla.com/D47094
fb5863ee4d37cad18f686064108e600ae37973b7: Bug 1572651 - (Part 2) Split BoxModelHighlighter into observer and renderer parts. r=pbro,jdescottes
Razvan Caliman <rcaliman@mozilla.com> - Thu, 10 Oct 2019 14:15:22 +0000 - rev 497109
Push 114148 by shindli@mozilla.com at Mon, 14 Oct 2019 10:49:50 +0000
Bug 1572651 - (Part 2) Split BoxModelHighlighter into observer and renderer parts. r=pbro,jdescottes NOTE: To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter` Adding Julian as reviewer to check the sanity of the communication system (see `BoxModelHiglighterObserver` constructor and `BoxModelHighlighterRenderer.setMessageManager()`, `BoxModelHighlighterRenderer.onMessage()`, `BoxModelHighlighterRenderer.postMessage()`) and Patrick for the overall highlighter behavior which is mostly a clean split of the existing [`BoxModelHighlighter`](https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/devtools/server/actors/highlighters/box-model.js)). --- Depends on D47091 ## Preamble This patch looks more frightening than it actually is. Let me explain: The vast majority of the code in `box-model-highlighter-observer.js` and `box-model-highlighter-renderer.js` is a clean split of the code existing in `box-model-highlighter.js` into distinct parts which handle the node measurement (observer) and the drawing the highlighter (renderer). I kept the method names identical to help in matching them up with their original sources. There was no simple way chunk this without confusing the daylight out of you so I decided to co-locate all changes so it's easier to track and reference methods. I will detail below the important differences. ## Overview: The box model highlighter is split into two distinct parts: - an observer which monitors the node's position - a renderer which draws the highlighter on top of the node The renderer always lives in the parent process (browser window) and overlays an iframe with the highlighter markup: - either over the content if highlighting in the context of the content toolbox - or over the whole browser UI if highlighting in the context of the browser toolbox When in the context of the browser toolbox (i.e. highlighting the browser UI), both observer and renderer live in the parent process. Communication is done by direct calls. When in the context of the content toolbox (i.e. highlighting the page content), the observer lives in content process (so it can measure the node) while the renderer lives in the parent process. Communication is done by message passing via `MessageManager` (soon to be deprecated and replaced with JSWindowActor API) ## Notable differences after the split - the observer checks whether it is in the content process (aka child process) and sets up the highlighter in the parent process by using [`setupInParent()`](https://docs.firefox-dev.tools/backend/actor-e10s-handling.html) and establishes a communication system to it via message manager. If the observer is in the parent process (browser toolbox scenario), the renderer is setup directly via its constructor and no additional communication system is required. - whenever the node quads change (as determined by the untouched existing base class `auto-refresh.js`), the observer gathers the data about the node position and sends it over to the renderer. This happens in the `BoxModelHighlighterObserver._update()` (corresponding to the [`_update()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#361-383)). - the renderer expects its `render()` method to be called with the necessary node position information whenever it should update the highlighter. It is the entry point which then calls all the DOM manipulation methods copied over from the existing box model highlighter. - the only notable change in DOM manipulation methods is in `BoxModelHighlighterRenderer._updateBoxModel()` (corresponding to [`updateBoxModel()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#504-560)) where the `_nodeNeedsHighlighting()` is kept on the observer part and the canvas zoom adjustment is removed (`this.markup.scaleRootElement(this.currentNode, rootId)`) because the canvas is no longer influenced by the page zoom (the canvas lives in the browser window, not the content window) Differential Revision: https://phabricator.services.mozilla.com/D47092
5ef33867cacb34b48a89fef0c5aa08f38df67544: Bug 1572651 - (Part 1) Add highlighter renderer base class r=jdescottes,pbro,bgrins
Razvan Caliman <rcaliman@mozilla.com> - Thu, 10 Oct 2019 14:13:23 +0000 - rev 497108
Push 114148 by shindli@mozilla.com at Mon, 14 Oct 2019 10:49:50 +0000
Bug 1572651 - (Part 1) Add highlighter renderer base class r=jdescottes,pbro,bgrins **Update October 8** To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter` --- Adding Julian as reviewer to check the sanity of the communication system and Patrick for the overall highlighter behavior. --- This patch adds a base class for the renderer part of highlighters which is set up on the parent process in the browser window. This is used by the `BoxModelHighlighterRender` introduced by D47092 `HighlighterRenderer.init()` will create an HTML iframe and inject it to the appropriate position in the browser window in order to serve as a rendering surface for highlighters of the inspected page content (content toolbox) or the browser UI (browser toolbox). A host iframe is used until [Bug 1492582](https://bugzilla.mozilla.org/show_bug.cgi?id=1492582) is fixed because the browser window is XUL and does not support the anonymous canvas frame used by existing highlighters. The primary use case of `HighlighterRenderer` is as a base class for renderers which live in a separate process than the observers. This happens with highlighters for the content toolbox. Therefore, it provides methods to setup a communication system (via MessageManager for now) whereby the observer can send messages to the renderer and vice-versa: `setMessageManager()`, `postMessage()` and `onMessage()`. I used the existing code from [`AccessibilityParent`](https://searchfox.org/mozilla-central/source/devtools/server/actors/accessibility/accessibility-parent.js) as a reference for this. Classes that extend HighlighterRenderer must implement: - a typeName representing the highlighter type; used to differentiate between other types of messages when the Message Manager is used; - a _buildMarkup() method to generate the highlighter markup; - a `render()` method to update the highlighter markup when given new information about the observed node. NOTE: A temporary pink outline is set on the highlighter surface as a quick visual check to show its extent depending on context: browser toolbox or content toolbox. This will be removed before landing. Differential Revision: https://phabricator.services.mozilla.com/D47091
dc0dd7454893619d22b5c1c665808d7596a63307: Bug 1568126 - Part 1: Use the contextual WalkerFront in _hideHighlighterIfDeadNode. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Wed, 09 Oct 2019 21:07:12 +0000 - rev 497039
Push 114147 by ccoroiu@mozilla.com at Thu, 10 Oct 2019 09:56:56 +0000
Bug 1568126 - Part 1: Use the contextual WalkerFront in _hideHighlighterIfDeadNode. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48579
906c06cac59dec7624994e232c70dab82ef17ef5: Bug 1568126 - Part 1: Use the contextual WalkerFront in _hideHighlighterIfDeadNode. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Wed, 09 Oct 2019 07:17:32 +0000 - rev 497008
Push 114147 by ccoroiu@mozilla.com at Thu, 10 Oct 2019 09:56:56 +0000
Bug 1568126 - Part 1: Use the contextual WalkerFront in _hideHighlighterIfDeadNode. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48579
32d326f04819aad8813f0c6c70c35247014e227a: Bug 1582886: Test with a new test page which has a visited and an unvisited link. r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 09 Oct 2019 07:18:31 +0000 - rev 496904
Push 114147 by ccoroiu@mozilla.com at Thu, 10 Oct 2019 09:56:56 +0000
Bug 1582886: Test with a new test page which has a visited and an unvisited link. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48485
f4421c5861f8ceb1026993f1768ee786459d1f17: Bug 1586634: Add a test for the pref which enables the compatibility tool. r=pbro,rcaliman
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 09 Oct 2019 00:35:40 +0000 - rev 496847
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586634: Add a test for the pref which enables the compatibility tool. r=pbro,rcaliman Differential Revision: https://phabricator.services.mozilla.com/D48324
5a4992c15f6693c72b08bfc106e48020463696a9: Bug 1586634: Enable the compatibility tool by devtools.inspector.compatibility.enabled pref. r=pbro,rcaliman
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 09 Oct 2019 00:35:32 +0000 - rev 496846
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586634: Enable the compatibility tool by devtools.inspector.compatibility.enabled pref. r=pbro,rcaliman Differential Revision: https://phabricator.services.mozilla.com/D48323
c1b36e863e15d29e15651c99d7f85c866323d168: Bug 1586806 - Use the WalkerFront from the currently selected element in addNode(). r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 06:58:31 +0000 - rev 496755
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586806 - Use the WalkerFront from the currently selected element in addNode(). r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48426
878ed0ad732fcf970f18f5d3047bdc79ef56644c: Bug 1586798 - Use WalkerFront from the currently selected element in onTagEdit(). r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 06:59:11 +0000 - rev 496754
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586798 - Use WalkerFront from the currently selected element in onTagEdit(). r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48433
4e28d8852735969c33b88a1ace20ca8284820484: Bug 1586801 - Use the contextual WalkerFront in _duplicateNode(). r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 07:07:02 +0000 - rev 496753
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586801 - Use the contextual WalkerFront in _duplicateNode(). r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48442
56a4078555c31112ba6df678896645da91a2891b: Bug 1586804 - Use the contextual WalkerFront in the markup hide shortcut handler. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 07:07:29 +0000 - rev 496752
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586804 - Use the contextual WalkerFront in the markup hide shortcut handler. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48445
ab2e082c7d2889c8de7a05a882c0517e169d2cda: Bug 1586807 - Make pseudoclass locking work with Fission. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 06:57:48 +0000 - rev 496751
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586807 - Make pseudoclass locking work with Fission. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48447
83a543bc7f1503f5955b98b7cddc80ab88dc4ddd: Bug 1586796 - Make drag/drop nodes work with Fission. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 06:57:26 +0000 - rev 496750
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586796 - Make drag/drop nodes work with Fission. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48449
65b301040f8a0a3355fc55e533057d6c393189cb: Bug 1586800 - Use the contextual WalkerFront in _deleteNode(). r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Tue, 08 Oct 2019 06:59:39 +0000 - rev 496749
Push 114146 by dmajor@mozilla.com at Wed, 09 Oct 2019 17:52:49 +0000
Bug 1586800 - Use the contextual WalkerFront in _deleteNode(). r=pbro Differential Revision: https://phabricator.services.mozilla.com/D48439
ec52c8aa2b8e2291f542b392a345a528f95d4407: Bug 1581799 - fix: disable node or color picker when one is on r=pbro
Shobhit <chittorashobhit@gmail.com> - Wed, 02 Oct 2019 09:03:07 +0000 - rev 496146
Push 114143 by rgurzau@mozilla.com at Mon, 07 Oct 2019 09:35:08 +0000
Bug 1581799 - fix: disable node or color picker when one is on r=pbro Before this fix the user could turn on both, the color picker as well as the node picker / inspector. That leads to the problem where in the node picker works fine but the color picker gets stuck at the same place on the screen. Differential Revision: https://phabricator.services.mozilla.com/D47381
21fecf0dea2e623cedb60348339b22613a29a6ae: Bug 1475182: Make the duration of animations longer by the playback rate. r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Tue, 01 Oct 2019 06:59:03 +0000 - rev 495782
Push 114140 by dvarga@mozilla.com at Wed, 02 Oct 2019 18:04:51 +0000
Bug 1475182: Make the duration of animations longer by the playback rate. r=pbro Differential Revision: https://phabricator.services.mozilla.com/D47726
6f09a19d3fa4c010f16ad16c0996041f9e0d638b: Bug 1583444 - Stop using win.top in devtools/shared/layout/utils.js r=pbro
Julian Descottes <jdescottes@mozilla.com> - Mon, 30 Sep 2019 09:53:15 +0000 - rev 495617
Push 114140 by dvarga@mozilla.com at Wed, 02 Oct 2019 18:04:51 +0000
Bug 1583444 - Stop using win.top in devtools/shared/layout/utils.js r=pbro Depends on D46957 We are updating three call sites that were still relying on window.top to get the topmost window. For `getFrameOffsets` and `getRect`, they are currently only called with a non-null `boundaryWindow` argument. That's why this didn't trigger any regression. For `getFrameElement`, I could only find STRs that don't have any user impact. For instance, when the BrowserToolbox debugs a page where you open DevTools, this will load the toolbox in an iframe. This load will trigger `onFrameLoad` in the walker actor. And because we were using `win.top`, getFrameElement would return null, and onFrameLoad will not emit mutations. But I couldn't see any scenario where this had an actual impact for users. Differential Revision: https://phabricator.services.mozilla.com/D46958
bd3ef721979101f3186db162e1dcb9801f23d548: Bug 1581339 - Inactive CSS: Tooltip wording updates r=flod,fluent-reviewers,pbro
Michael Ratcliffe <mratcliffe@mozilla.com> - Thu, 26 Sep 2019 12:53:28 +0000 - rev 495403
Push 114134 by ccoroiu@mozilla.com at Mon, 30 Sep 2019 09:57:15 +0000
Bug 1581339 - Inactive CSS: Tooltip wording updates r=flod,fluent-reviewers,pbro Differential Revision: https://phabricator.services.mozilla.com/D47119
5249dd6e05b561fa0e6951ebdbefeec5739d4591: Bug 1581008: Add test for :visited inactive CSS message. r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 25 Sep 2019 14:41:58 +0000 - rev 495024
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1581008: Add test for :visited inactive CSS message. r=pbro Depends on D45626 Differential Revision: https://phabricator.services.mozilla.com/D46257
887394ac57bcb1e499bbf069de2b673e2e09f8f9: Bug 1581008: Add inactive CSS message for properties that are impossible to override. r=pbro,fluent-reviewers,flod
Daisuke Akatsuka <daisuke@birchill.co.jp> - Thu, 26 Sep 2019 01:53:40 +0000 - rev 495023
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1581008: Add inactive CSS message for properties that are impossible to override. r=pbro,fluent-reviewers,flod Depends on D45624 Differential Revision: https://phabricator.services.mozilla.com/D45625
3bfc227fb884affcb46d9261a5a0460b125c1494: Bug 1579582 - 'grid-column' etc have an effect for abs.pos. boxes with a grid container as 'containing block' r=pbro
Michael Ratcliffe <mratcliffe@mozilla.com> - Wed, 25 Sep 2019 11:20:40 +0000 - rev 494903
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1579582 - 'grid-column' etc have an effect for abs.pos. boxes with a grid container as 'containing block' r=pbro Differential Revision: https://phabricator.services.mozilla.com/D45830
1208c70dd3bd31c283c884a57000e2761fc09cb3: Bug 1581008: Add test for :visited inactive CSS message. r=pbro
Daisuke Akatsuka <daisuke@birchill.co.jp> - Tue, 24 Sep 2019 08:50:18 +0000 - rev 494880
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1581008: Add test for :visited inactive CSS message. r=pbro Depends on D45626 Differential Revision: https://phabricator.services.mozilla.com/D46257
d69f8f5f9db4cadd95aa11f4c50570dbda413718: Bug 1581008: Add inactive CSS message for properties that are impossible to override. r=pbro,fluent-reviewers,flod
Daisuke Akatsuka <daisuke@birchill.co.jp> - Wed, 25 Sep 2019 07:45:15 +0000 - rev 494879
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1581008: Add inactive CSS message for properties that are impossible to override. r=pbro,fluent-reviewers,flod Depends on D45624 Differential Revision: https://phabricator.services.mozilla.com/D45625
7be1052a93279bde9838f35104232895bd8a9432: Bug 1551581 - New InactiveCSS rule to show warning when display:* used on a floated element; r=miker,pbro,fluent-reviewers,flod
biboswan <biboswan98@gmail.com> - Tue, 24 Sep 2019 12:55:13 +0000 - rev 494758
Push 114127 by rgurzau@mozilla.com at Tue, 24 Sep 2019 21:57:45 +0000
Bug 1551581 - New InactiveCSS rule to show warning when display:* used on a floated element; r=miker,pbro,fluent-reviewers,flod Differential Revision: https://phabricator.services.mozilla.com/D45309