1911627 - Toggling style rule in Inspector breaks resize of resizable element

Status: RESOLVED FIXED

(DevTools :: Inspector: Rules, defect, P3)

Description

[firefoxbugs]

Attachment: resizebug.htm

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

Load the attached demo file (resizebug.htm). (Instructions copied into it also for easy reference.)

To trigger the bug, open Inspector (Ctrl+Shift+C), click on the nested <div>, and toggle on or off the style applied to the element. (The exact rule makes no difference. It could be anything.) The resize behavior of its parent <div> is now broken.

Actual results:

To see that it's broken, click and drag the resize handle a short distance to the right. As soon as you move off of the resize handle, the mouse cursor switches back from resize to default, when it should continue showing the resize cursor for as long as the mouse button is held down. Now release the mouse button. Now, when simply hovering over the resize handle, the element will be resizing.

(Reasons for doing it in the nested <div> instead of the <div> itself: To show it's not limited to the resizing <div> itself, and because resizing the <div> deletes disabled styles from the style attribute.)

You can stop it from resizing on hover by clicking on the resize handle. But it's still broken until you click away from this element in the Inspector (e.g. click on another element, or click on Console). Then it will start working correctly again. If you did not click again on the resize handle but left it in the actively resizing state, it will remain in that state, resizing on hover, even if you do click away from the element on which you toggled the style (in this case, the nested <div>), but the behavior will resolve after you click on the resize handle and have clicked away from that element (even if you go back to that element before cancelling the actively resizing state).

Observed on Firefox 128.0.3 (64-bit) on Linux, in case that makes any difference. Haven't tried other versions or platforms.

Expected results:

Using DevTools should not break resizing of resizable element.

Comment 1

[Julian Descottes [:jdescottes] (PTO -> Jan 5th)]

It looks like the issue occurs when you start editing a property and then resize the element without submitting the property change. We probably have a drag listener which conflicts with the one used for the resize handle.

Comment 2

[Julian Descottes [:jdescottes] (PTO -> Jan 5th)]

It doesn't seem related to our dragging code, disabling it fully doesn't prevent the issue.

Comment 3

[firefoxbugs]

Still reproducible on Firefox 141.0.3. I should note that the Web Developer Tools must be docked (left, bottom, right) for the bug to reproduce. It does not reproduce if it is in a separate window. Maybe that detail is helpful.

Comment 4

[Julian Descottes [:jdescottes] (PTO -> Jan 5th)]

Forgot to CONFIRM the bug.

Simplified STRs:

• open data:text/html,<div style="resize:horizontal;color:red;width:200px; height:200px;background:wheat;overflow:auto">
• open inspector
• start editing any rule property VALUE (name doesn't work)
• start resizing

The issue boils down to the fact that on blur, we destroy the inplace editor https://searchfox.org/mozilla-central/rev/1d3c8311925d252ae79c223a53b65e667c810805/devtools/client/inspector/rules/views/text-property-editor.js#383-396

done: this.#onValueDone,
destroy: onValueDonePromise => {
  const cb = this.update;
  // The `done` callback is called before this `destroy` callback is.
  // In #onValueDone, we might preview/set the property and we want to wait for
  // that to be resolved before updating the view so all data are up to date (see Bug 1325145).
  if (
    onValueDonePromise &&
    typeof onValueDonePromise.then === "function"
  ) {
    return onValueDonePromise.then(cb);
  }
  return cb();
},

Which calls this.update(), which will finally focus another element https://searchfox.org/mozilla-central/rev/1d3c8311925d252ae79c223a53b65e667c810805/devtools/client/inspector/rules/views/text-property-editor.js#513-517,606-609,817-823

/**
 * Populate the span based on changes to the TextProperty.
 */
// eslint-disable-next-line complexity
update = () => {
...
  let focusedElSelector = null;
  if (this.valueSpan.contains(this.doc.activeElement)) {
    focusedElSelector = findCssSelector(this.doc.activeElement);
  }
...
  if (focusedElSelector) {
    const elementToFocus = this.doc.querySelector(focusedElSelector);
    if (elementToFocus) {
      elementToFocus.focus();
    }
  }
};

This seems to steal the focus from the resize feature, but I can't reproduce without devtools being involved.

Comment 5

[Julian Descottes [:jdescottes] (PTO -> Jan 5th)]

Attachment: Bug 1911627 - [devtools] Avoid stealing focus after ruleview editor destruction

Comment 6

[Julian Descottes [:jdescottes] (PTO -> Jan 5th)]

Note that the ruleview also steals the focus in very basic cases such as a page with an input, eg data:text/html,<input style="color:red">

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2d34e37e5d86
https://hg.mozilla.org/integration/autoland/rev/5e3597f140f6
[devtools] Avoid stealing focus after ruleview editor destruction r=devtools-reviewers,nchevobbe

Comment 8

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/5e3597f140f6