Open Bug 1699863 Opened 5 years ago Updated 4 years ago

input.focus() implicitly scrolls the view to the focus in async way

Categories

(Core :: DOM: Selection, defect, P3)

Firefox 86
defect

Tracking

()

Tracking Status
firefox-esr78 --- unaffected
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fix-optional

People

(Reporter: osama.dubai, Unassigned)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

when you try to edit a saved bookmark, the cursor is at the end of the name field, it used to be at the binging of the name field like any other browser ( edge of chrome)

Actual results:

the name field is highlighted ad the cursor at the end of the name

Expected results:

the cursor should be at the beginning of the name as any other browser or firefox before Ver. 84

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Bookmarks & History
Summary: Bookmarks issue → Editing a saved bookmark, cursor is at end of name field instead of beginning

Hi sam!
I was unable to reproduce this issue in the latest Nightly version 89.0a1 (2021-03-23)(64-bit) on Windows 10

When you edit a bookmark, the bookmark name is displayed highlighted. Using the left arrow key on the keyboard, the cursor will be displayed at the beginning of the bookmark name. The same happens if you use the up arrow key on the keyboard.
Could you please try to reproduce it in the latest Nightly and tell us your input? You can download it from here: https://nightly.mozilla.org/
Also, you can attach a screen recording showing the problem.
Thanks!

Flags: needinfo?(osama.dubai)

(In reply to Marcela from comment #3)

Hi sam!
I was unable to reproduce this issue in the latest Nightly version 89.0a1 (2021-03-23)(64-bit) on Windows 10

When you edit a bookmark, the bookmark name is displayed highlighted. Using the left arrow key on the keyboard, the cursor will be displayed at the beginning of the bookmark name. The same happens if you use the up arrow key on the keyboard.
Could you please try to reproduce it in the latest Nightly and tell us your input? You can download it from here: https://nightly.mozilla.org/
Also, you can attach a screen recording showing the problem.
Thanks!

Hi ,
I'm using 86.0.1, 64-bit on Windows 10, this is the latest update as far as i know, I'm not sure if its fixed on the ver you are using, but to reproduce this issue, is to bookmark any website ( long name ) , then try to edit the name, the cursor is at the end of the name field,

Flags: needinfo?(osama.dubai)

I have tried reproducing this on my end with no luck (Attaching video of me demonstrating it's working as expected).
Please add a video showing the issue, and test this issue on the latest nightly build as well. Download the build from here: https://www.mozilla.org/en-US/firefox/nightly/all/
Also, please attach the about:support data (Help > troubleshooting information > click "copy raw data to clipboard" button).

Firefox Nightly is made by codes and fixes made by Mozilla developers, that are compiled into a common code repository (Mozilla-central) to create a pre-release version of Firefox for testing purposes. After the code on Nightly matures, it is merged into stabilization repositories (Beta, ESR, and Dev Edition) where that code will be polished until reaching the final version of Firefox (Release).

Flags: needinfo?(osama.dubai)

(In reply to Marcela from comment #5)

I have tried reproducing this on my end with no luck (Attaching video of me demonstrating it's working as expected).
Please add a video showing the issue, and test this issue on the latest nightly build as well. Download the build from here: https://www.mozilla.org/en-US/firefox/nightly/all/
Also, please attach the about:support data (Help > troubleshooting information > click "copy raw data to clipboard" button).

Firefox Nightly is made by codes and fixes made by Mozilla developers, that are compiled into a common code repository (Mozilla-central) to create a pre-release version of Firefox for testing purposes. After the code on Nightly matures, it is merged into stabilization repositories (Beta, ESR, and Dev Edition) where that code will be polished until reaching the final version of Firefox (Release).

Thanks Marcela ,
actually, you are demonstrating the issue in your video as I experience it, in your video, the last word in the mane in " internet ", when you edit the bookmark, the cursor is on the last word, most probably you hit up or left arrow to go to the beginning of the bookmark name.
if you try the same process with Edge or chrome ( and even Firefox before Ver 84) , you will note that the cursor at the beginning of the bookmark name.
in regard to installing beta ver, I really need my laptop stable for work and i cant test beta on it.

Flags: needinfo?(osama.dubai)

do you need any more information?

Hi again and thanks for your information.
I think I know what the problem is: When you edit a bookmark with a very long name, the moment you open the panel you only see the last words of that name instead of the first few words right? that's what the problem is here. I was able to reproduce this issue now, it was a little confusing when the mouse cursor was mentioned.

I've run mozregression and this is the push log with the error:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=61ef4618e39efac06e2202782d12b98ffed08e4b&tochange=8ae44c88ef965eaedf349b1bb7f3f247740f0263

I will update the flags and set a component for this issue. The severity suggested is S3.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true

correct and thank you, at my work, i save a lot of internal websites, i bookmark them with the date to make sure I have the correct information, I put the date at the beginning. please let me know when you have any update

Updating summary.

From the regression range, it looks like bug 1679461, I'm not sure if that change was intentional or not though.

:saschanaz could you have a look please?

Severity: S3 → --
Flags: needinfo?(krosylight)
Regressed by: 1679461
Summary: Editing a saved bookmark, cursor is at end of name field instead of beginning → For preselected text, the end of the text is shown instead of the beginning

Also moving to Core / DOM Selection for now as that seems more appropriate.

Component: Bookmarks & History → DOM: Selection
Product: Firefox → Core

Could you point which line selects the Name field in the panel, as I'm not very familiar with that part? Thanks!

Flags: needinfo?(krosylight) → needinfo?(standard8)

not sure if you are asking me , but you can see the video Marcela posted, the name field is there, i hope this helps

(In reply to Kagami :saschanaz from comment #14)

Could you point which line selects the Name field in the panel, as I'm not very familiar with that part? Thanks!

I believe it is this code: https://searchfox.org/mozilla-central/rev/0e3d2eb698a51006943f3b4fb74c035da80aa2ff/browser/components/places/content/editBookmark.js#345-373

Flags: needinfo?(standard8) → needinfo?(krosylight)

Thank you guys, please let me know when this been resolved, or you need any more information. as long as I have your attention, anyone has any issue listening to iheart.com ?? it crashed on me multiple times and the broadcast keeps cutting off? I'm not sure it's just me or it's happening to other users?

(In reply to sam from comment #17)

Thank you guys, please let me know when this been resolved, or you need any more information.

When this bug gets resolved, it'll be marked as "fixed" and you'll be notified about it. The fix will then take several weeks to get out to a released build.

as long as I have your attention, anyone has any issue listening to iheart.com ?? it crashed on me multiple times and the broadcast keeps cutting off? I'm not sure it's just me or it's happening to other users?

Please don't mix multiple issues in bugs - this can confuse the bugs and make it harder for us to get the issues resolved. For this specific item, I suggest raising an question on our support site at https://support.mozilla.org

Flags: needinfo?(krosylight)
Summary: For preselected text, the end of the text is shown instead of the beginning → select() and setSelectionRange() implicitly scrolls the view to end

Okay, so this has been an existing issue and now also applies to select().

So we have two options here:

  1. Drop our scrolling behavior for select() and setSelectionRange()
  2. Or, for now just replace the select() call with elt.setSelectionRange(0, elt.value.length, "backward") to workaround this. backward will put the cursor to the start position in this case.
  3. Or, add elt.scrollTo(0, 0), it will scroll back to the start position.

I'm not sure whether option 1 would have significant web compat issue. Masayuki, do you have an opinion?

Flags: needinfo?(masayuki)

As you filed the spec issue, the API should have the scroll option like .focus().

On the other hand, scrolling to the end of <input> or <textarea> is odd at least to me because the selection start is start of the editor. So, I mean that it might be better to scroll to the selection start position rather than end position. But if you don't want to take the new web-compat issue right now, I think #2 is reasonable to me.

Flags: needinfo?(masayuki)
Severity: -- → S3
Priority: -- → P3

FYI I think Neil has fixed the original issue in bug 1703002 by using preventScroll on focus. It sounds like there is still a spec issue here, so I'll leave this open for others to decide.

See Also: → 1703002

Wait, I just remembered that bug 1680951 tried fixing this issue, but turns out this still happens? I'll take a look.

Assignee: nobody → krosylight
See Also: → 1680951
Summary: select() and setSelectionRange() implicitly scrolls the view to end → select() and setSelectionRange() implicitly scrolls the view to end if it has focus
Summary: select() and setSelectionRange() implicitly scrolls the view to end if it has focus → select() implicitly scrolls the view to end if it has focus

Hmm, so this is caused by nsTextControlFrame::ScrollSelectionIntoViewAsync() being async. .select() following .focus() changes the selection before actual scrolling and thus affects the behavior.

Summary: select() implicitly scrolls the view to end if it has focus → focus() implicitly scrolls the view to the focus in async way
Summary: focus() implicitly scrolls the view to the focus in async way → input.focus() implicitly scrolls the view to the focus in async way

I'd like to wait and see where the spec discussion goes, although it's not any active now.

Assignee: krosylight → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: