Closed Bug 1939206 Opened 7 months ago Closed 6 months ago

Text selection with mouse in text boxes of add-on option pages behaves strangely

Categories

(Toolkit :: Add-ons Manager, defect, P2)

Product:
Toolkit
Component:
Add-ons Manager
Version:
Firefox 135
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
136 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- wontfix
firefox133 --- wontfix
firefox134 --- wontfix
firefox135 --- verified
firefox136 --- verified

People

(Reporter: farblos, Assigned: rpl)

References

(Regression)

Details

(Keywords: nightly-community, regression, Whiteboard: [addons-jira])

Attachments

(3 files)

Bug 1939206 - Add display grid to about:addons inline options browser element. r?robwu!
48 bytes, text/x-phabricator-request
Details | Review
Screencast from 2025-01-09 22-24-47.webm
184.71 KB, video/webm
Details
Bug 1939206 - Add display grid to about:addons inline options browser element. r?robwu!
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-release+
Details | Review

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

Steps to reproduce:

Create a minimal extension consisting of the following two files in a newly created directory:

manifest.json:

{
  "name": "Test",
  "description": "Test",
  "version": "2.8",
  "options_ui": {"page": "options.html"},
  "manifest_version": 2
}

options.html:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>
    <title>Options</title>
  </head>
  <body>
    <input type="text" value="foobarbazfoobarbazfoobarbaz"/>
  </body>
</html>

Start FF nightly with a fresh profile, go to about:debugging#/runtime/this-firefox and load above extension as temporary add-on.

Go to about:addons => extensions, select to show the extension preferences of the temporary "Test" add-on.

Single-click into the text box displaying ...foobarbaz... using the mouse to focus the text box.

Single-click and drag into the text box displaying ...foobarbaz... to select some text without releasing the mouse button.

Actual results:

The selection is not extended, but the cursor follows the mouse until you release the mouse button. After releasing the mouse button the selection shows up and extends even though the mouse button is released already.

Expected results:

"Normal" mouse selection behavior: When you start dragging, the selection is extended, when you release the mouse button, the selection ends.

Summary: Text selection with mouse in text boxes of option pages behaves strangely → Text selection with mouse in text boxes of add-on option pages behaves strangely

This is not a particularly new issue ... 124 and older do not seem to feature it, but 128 and newer do.

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Product: Firefox → WebExtensions

The entire options pane will begin dragging instead of being text-selected.
STR:

  1. Load the test extension from about:debugging
  2. Open the extension options from about:addons
  3. Click on the input field to focus the input field.
  4. (Optionally) Click on the empty area below the input field to remove focus from the input field
  5. Try to select text by dragging the mouse

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=48bac688dfe1f85dd76be15f502c878df36fe54e&tochange=1d361a405f313da41f7d4bef7cc0376f29757bae

Status: UNCONFIRMED → NEW
status-firefox133: --- → wontfix
status-firefox134: --- → fix-optional
status-firefox135: --- → affected
status-firefox-esr115: --- → unaffected
status-firefox-esr128: --- → affected
Component: Untriaged → Add-ons Manager
Ever confirmed: true
Keywords: nightly-community, regression
OS: Unspecified → All
Product: WebExtensions → Toolkit
Regressed by: 1881055
Hardware: Unspecified → Desktop

:rpl, since you are the author of the regressor, bug 1881055, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(lgreco)

Set release status flags based on info from the regressing bug 1881055

status-firefox136: --- → affected

I just took a look into this regression, the only part of Bug 1881055 changes that could have triggered this regression was the removal of the stack XUL element as a parent of the browser XUL element and so I gave a try to re-add it to double-check if I was still able to reproduce the issue with the STR from comment 0.

With the changes from the patch attached in comment 6 the issue doesn't reproduce anymore, which isn't too surprising, but it is a bit surprising that the stack element (or the absence of it) triggers the different behavior.

Flags: needinfo?(lgreco)
Whiteboard: [addons-jira]
Assignee: nobody → lgreco
Attachment #9446290 - Attachment description: WIP: Bug 1939206 - Add back the stack parent element to the about:addons inline options browser element. → Bug 1939206 - Add back the stack parent element to the about:addons inline options browser element.
Status: NEW → ASSIGNED
Attachment #9446290 - Attachment description: Bug 1939206 - Add back the stack parent element to the about:addons inline options browser element. → Bug 1939206 - Add display grid to about:addons inline options browser element.

Some more than 2 cents:

  • Bug 1939284 might be also related to this one or, more precisely, to the removal of the stack element.
  • As mentioned in bug 1881055, the stack element was responsible for some white stripes or flashes in dark mode, and it would be great if your next fix would ensure that the option page does not suffer from these, again.
  • In the phabricator differential there have been some doubts what my expected behavior is. I'm not about dragging and dropping text, I just would like to select text in that input field with the mouse, like: 1st get focus on the field, then select (with pressed mouse button) the contained text, then release the mouse button and have the selection ready.
  • Most importantly: This stack element might be a red herring, since I just noticed that some strange mouse behavior is also present in FF 124, which still has the stack element. I can expand on that, but probably:

Would it be possible to get a pre-built patched version for Linux x64 with your tentative fixes? Or can I monkey-patch nightly installation somehow? Then I could check above items against that and provide more focused feedback. I currently don't have the resources to build FF from scratch ...

OK, I have been able to monkey-patch omni.ja in a current nightly but then suffered from test-fatigue and got incoherrent results. If you don't mind, I'll continue my tests tomorrow and provide some feedback. In short, with the current display: grid fix things seem to be a bit better, but not yet completely.

(In reply to farblos from comment #8)

Some more than 2 cents:

Thank you so much, the additional details are very useful and very much appreciated!

  • Bug 1939284 might be also related to this one or, more precisely, to the removal of the stack element.

Thanks for mentioning that other issue, I'm taking a look into it

  • As mentioned in bug 1881055, the stack element was responsible for some white stripes or flashes in dark mode, and it would be great if your next fix would ensure that the option page does not suffer from these, again.

yep, I agree, that is also a detail to keep an eye on.

  • In the phabricator differential there have been some doubts what my expected behavior is. I'm not about dragging and dropping text, I just would like to select text in that input field with the mouse, like: 1st get focus on the field, then select (with pressed mouse button) the contained text, then release the mouse button and have the selection ready.

Thanks for the confirmation!

  • Most importantly: This stack element might be a red herring, since I just noticed that some strange mouse behavior is also present in FF 124, which still has the stack element.

If it can still be reproduced, I'd be absolutely interested in knowing some more about the STR of this issue, in the meantime I'm going to share a link to a custom build with the patch attached to this bug so that you can more easily give it a try.

I can expand on that, but probably:

Would it be possible to get a pre-built patched version for Linux x64 with your tentative fixes? Or can I monkey-patch nightly installation somehow? Then I could check above items against that and provide more focused feedback. I currently don't have the resources to build FF from scratch ...

I have pushed the attached patch to try, the Ba job are the ones where the custom builds are linked to (in the "Artifacts and Debugging Tools" tab of the panel that is opened when you click on the Ba job), the linux-opt build should be this one:

STR:

  1. Install "Reject Service Worker" (https://addons.mozilla.org/en-US/firefox/addon/reject-service-worker/)
  2. Open about:addons > Extensions > "Reject Service Worker" > Options
  3. Type some text in the text field
  4. Try text by mouse dragging

I've done a bit of debugging. It looks like the browser somehow thinks that the <browser> hosting the inline options page is draggable, and that pressing the pointer and moving it while pressed initiates a drag&drop operation. This is strange, since the pointer press and drag operation, if any, should have been handled by the content within (i.e. the extension's options page).

There are work-arounds (putting display:grid or display:flex), but these also subtly affect the layout in other ways (in the form of reducing some spacing at the bottom, below the <browser>). These work-arounds seem reasonable if we want to resolve the regression quickly. It would be nice if we understand what is really happening, and fix the root cause though. The root cause is that pointer/drags are handled in the aboutaddons.html non-remote <browser> (tab browser) instead of the remote inline options <browser>.

I have simplified the test case further, as follows:

  1. Install a simple extension with an options page, e.g. https://addons.mozilla.org/en-US/firefox/addon/dont-track-me-google1/ (version 4.28)
  2. Visit about:addons and open the options page (Preferences) tab of the add-on.
  3. Click once inside the options page.
    Note: focusing the options page seems to be a prerequisite. Not doing this will result in the drag start to be no-op.
  4. Press the pointer inside the options page and start moving the mouse while pressed. Firefox will render a rectangle, visualizing an attempt to drag and drop it.

The bug is independent of parent nodes of the <browser> element. If I patch this.appendChild(browser) (whether with omni.ja patching or with devtools breakpoint) to append to document.body instead of the current element, then the bug is still observed.

As I noted in a review comment, it is not the <stack> that got rid of the bug, but the display:grid style on the stack. I also tried display:flex, and that has the same effect: applying either style to the <browser> element prevents the pointer-press-and-drag from starting a drag&drop operation. (note: if you change the style at runtime, e.g. through the devtools, click anywhere in the page before dragging again to make sure that the drag&drop behavior reflects the current style)

Here is a code snippet that peeks at a notification that is triggered when a drag is sent.

if(obs){Services.obs.removeObserver(obs, obs.topic)}
var obs = {topic:"on-datatransfer-available",observe(subj,topic,dat){ console.log(subj,topic,dat);Array.from(subj.items).forEach(i=>i.getAsString(res=>{console.log(i.type, res)})) }};
Services.obs.addObserver(obs, obs.topic)

With the above code snippet, nothing is printed when display:grid or display:flex is used.
Without the work-around, the following information is logged, which strongly suggests that for some reason, the browser thinks that the inline options browser's <browser> element should be draggable (conceptually as if it has the draggable=true HTML attribute).

DataTransfer { dropEffect: "none", effectAllowed: "uninitialized", items: DataTransferItemList, types: (4) […], files: FileList [], mozCursor: "auto", mozUserCancelled: false, mozSourceNode: null, mozItemCount: 1, sourceTopWindowContext: null }
 on-datatransfer-available null

text/_moz_htmlcontext <html lang="en-US" dir="ltr"><body></body></html>

text/_moz_htmlinfo 0,0

text/html <browser type="content" disableglobalhistory="true" messagemanagergroup="webext-browsers" id="addon-inline-options" class="addon-inline-options" transparent="true" forcemessagemanager="true" autocompletepopup="PopupAutoComplete" initialBrowsingContextGroupId="26" remote="true" style="height: 24px;/*! display: grid; */"></browser>

text/plain <empty string>
Attachment #9446290 - Attachment description: Bug 1939206 - Add display grid to about:addons inline options browser element. → Bug 1939206 - Prevent dragstart on the about:addons options_ui page's browser element. r?robwu!

New push to try for the new reworked version of the attached patch:

The try build of comment#13 fixed the issue on windows11.

Luca, thanks for the patched binary, but I understood that Rob's new patch has rendered it kind of outdated.

And Rob, thanks for your next patch! I applied it directly in omni.ja and it fixes the problem of this bug all right.

So from my above "more than 2 cents" only that "strange mouse behavior" is actually left, also in 136.0a1 with Rob's latest patch. It might be related to this bug or it might not, please judge yourself. I can open a new bug if required:

  1. Follow the initial test instructions and open the temporary extension's preferences.
  2. Press Ctrl+R to reload the extension's preferences (not strictly required but makes the issue easier reproducible IME).
  3. Focus the ...foobarbaz... input field with a single mouse click.
  4. Now Click again in the input field to select the text from right to left, keep the button pressed. Move the mouse over the left end of the input field and then up towards to the URL bar.
  5. When over the URL bar, release the button.

For me, that selects the input field text, but also the text outside the option page. Plus, when I move the mouse (with released button) back to the input field, the text selection in the input field starts moving again, as if the mouseup event has not been delivered to the input field.

I took a screen capture of the issue, pls see attached file. Sometimes the behavior does not reproduce on first attempt, but only when reloading the page with Ctrl+R.

See Also: → 1798257

(In reply to farblos from comment #15)

Looks like Bug 1798257

(In reply to Alice0775 White from comment #17)

Looks like Bug 1798257

Very likely at least related, indeed, thanks for the pointer. There are also some differences, though:

  • I cannot reproduce bug 1798257 on Linux :-) but I may be missing something here
  • Bug 1798257 does not mention that the selection extends to unexptected areas, only that the mouseup event for the end-of-selection is not delivered
  • While the doubleclick makes my recipe from comment #15 more reproducible (and probably is even a prerequisite that I did not notice), it is not required to experience the lost mouseup event

The severity field is not set for this bug.
:zombie, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(tomica)
Severity: -- → S4
Flags: needinfo?(tomica)
Priority: -- → P2
Attachment #9446290 - Attachment description: Bug 1939206 - Prevent dragstart on the about:addons options_ui page's browser element. r?robwu! → Bug 1939206 - Add display grid to about:addons inline options browser element. r?robwu!
Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/32bee761bfc6 Add display grid to about:addons inline options browser element. r=robwu

https://hg.mozilla.org/mozilla-central/rev/32bee761bfc6

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
status-firefox136: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch

The patch landed in nightly and beta is affected.
:rpl, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(lgreco)
Attachment #9462551 - Flags: approval-mozilla-beta?

beta Uplift Approval Request

  • User impact if declined: Text selection with mouse in text boxes inside the add-on option pages embedded in the about:addons page would not work correctly (and the entire browser element where the add-on options page is hosted would be dragged instead)
  • Code covered by automated testing: no
  • Fix verified in Nightly: no
  • Needs manual QE test: yes
  • Steps to reproduce for manual QE testing: We have manually verified the fix locally, but it would be good to QA to also verify it explicitly when it has been uplifted, the STR to use is the one described in comment 11
  • Risk associated with taking this patch: Low
  • Explanation of risk level: The fix is a one line change to the css associated to the parent element (setting it to display grid as it was when the nested browser was parented to a stack xul element), there should be no other impact besides a small visual change, a small margin to the bottom of the nested browser element)
  • String changes made/needed: -
  • Is Android affected?: no
Flags: qe-verify+
Attachment #9462551 - Flags: approval-mozilla-release?

Comment on attachment 9462551 [details]
Bug 1939206 - Add display grid to about:addons inline options browser element. r?robwu!

135 is in RC now, moving the request over accordingly.

Flags: needinfo?(lgreco)
Attachment #9462551 - Flags: approval-mozilla-beta?
Attachment #9462551 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified as Fixed. Tested on the latest Nightly (136.0a1/20250129170612), Beta (135.0/20250130025433 from https://treeherder.mozilla.org/jobs?repo=mozilla-release&revision=b720ec65473471747cc9f8360d8d8c9e260fb4bb with the fix) and Beta (135.0/20250127201358 without the fix, for comparison) on Windows 10 and macOS 11.3.1, using both the extension from Comment 0 and the extension and STR from Comment 11.

With the fix, normal mouse selection behavior is achieved i.e. when clicking the mouse button and dragging the mouse cursor, the selection is extended and when releasing the mouse button, the selection ends.

Status: RESOLVED → VERIFIED
status-firefox135: fixed → verified
status-firefox136: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: