[markup-view] Scrolling element into view on click may move target element of click event

NEW
Unassigned

Status

()

Firefox
Developer Tools: Inspector
P2
normal
2 years ago
3 months ago

People

(Reporter: arni2033, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox43 affected)

Details

User Story

Additional STR from bug 1197250 (visit it to see video):
1. Open attached page "testcase.html" (you can open "testcase.html" from this bug)
2. Press Ctrl+Shift+K to open console
3. Click Inspector tab in devtools
4. [don't scroll markup-view] Click (ev) button next to closing angle bracket of <body>

Result:       Markup-view scrolled to the top
Expectations: It shouldn't be scrolled; and (ev) button should open Event Listeners popup

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8651108 [details]
testcase.html

STR:   (Nightly 43.0a1 (2015-08-20))
1. Open attached page "testcase.html"
2. Open devtools-Inspector
3. Scroll Down (to the very bottom) and click closing angular bracket of <body> 2 times

Result:       markup-view scrolls to the beginning of <body>, so I have to scroll down and click the
              closing bracket again. In fact, that will never open textarea to create attribute

Expectations: Markup-view should stay still and texratea should open normally

Note:         "In the field" elements are not as big as <body> in my example, so clicking closing 
              bracket the_second_time actually works. But you still need to spend 2 clicks on it
(Reporter)

Comment 1

2 years ago
Created attachment 8651112 [details]
2015.08.21 19-51-57.webm

(!) I meant that in Step 3 you should doubleclick, and first click's target is closing bracket and the second click's target is the special <span.newattr>. Or you can click the closing bracket, then doubleclick the <span.newattr>.
It doesn't matter, because none of these 2 ways of clicking to create new attribute work here.
(Reporter)

Comment 2

2 years ago
Hello, Patrick. Please have a look at these bugs: this one, bug 1197252 and bug 1197250
All these issues are caused by element in markup-view being scrolled into view when first clicked
I think the mechanism should be changed: either scroll element only after mouseup or don't scroll at all
Should it be discussed somewhere?
Flags: needinfo?(pbrosset)
(In reply to arni2033 from comment #2)
> Hello, Patrick. Please have a look at these bugs: this one, bug 1197252 and
> bug 1197250
> All these issues are caused by element in markup-view being scrolled into
> view when first clicked
> I think the mechanism should be changed: either scroll element only after
> mouseup or don't scroll at all
> Should it be discussed somewhere?
Thanks for reporting these issues Arni. These are indeed pretty frustrating.

Just to make sure we're on the same page, can you confirm these are the 2 broader issues you're seeing:

1 - comment 0 of this bug as well as bug 1197252 comment 0 and bug 1197250 comment 0 are all about the markup-view auto-scrolling when you click somewhere, therefore making it impossible (or harder) to either add an attribute or click the (ev) icon, right?

2 - bug 1197252 comment 2 however is about the (ev) icon moving away from under your mouse when you click while the textcontent edit mode is on.

If you agree, could you mark bug 1197250 as duplicate of this one (and copy/paste the STRs from that bug here), and make sure that bug 1197252 is about the edit-mode + (ev) icon combined problem? Thanks.

I have made an attempt at a quick fix for the scrolling problem (1). I think it improves the experience, but I haven't had time to thoroughly test the various user flows. If you have some time, it'd be great if you could download one of the builds here and give it a test:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=26db9747cd79
(we'll have to wait a little bit before the various builds are done, but once done, click on "B" next to a Windows Opt build, and then click on the "Build" link in the lower left corner).
Flags: needinfo?(pbrosset) → needinfo?(arni2033)
(Reporter)

Comment 4

2 years ago
I agree, 1197250 is duplicate of this. 1st testcase in 1197252 is Dupe of this too (but it exposes another type of scrolling - "scroll to the end of element"). I'll edit that bug.
However, the 2nd testcase in 1197252 is about <span.newattr> disappearing, as you said.

So I suggested to disable "Scroll to element on click" in this bug (I also have thoughts for 1197252)

I'll tell you my results on testing a build if I have time
User Story: (updated)
Flags: needinfo?(arni2033)
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1197250
(Reporter)

Updated

2 years ago
See Also: → bug 1197252
(Reporter)

Comment 6

2 years ago
One more thing: I think that in the fix, scrolling could be disabled only when user clicks "special" elements which suggest an action on click.
Summary: [markup-view] It's impossible to create new attribute DoubleClicking on closing bracket (in some cases) → [markup-view] Scrolling element into view on click may move target element of click event
(Reporter)

Comment 7

2 years ago
I've tried the build http://ssmaker.ru/db21681d.png
This bug isn't presented there, but I noticed another issue: if I double-click an attribute, and then click another element (e.g. <head>) then textarea doesn't collapse. http://ssmaker.ru/1728e673.png

Also, I noticed that "scroll into view element on click" in devtools scrolls to the end of element if it gains focus, and to the beginning of element if I click within the element.
See Also: → bug 1202458
(Reporter)

Updated

2 years ago
Has STR: --- → yes
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P2
(Reporter)

Updated

a year ago
See Also: → bug 1241059
You need to log in before you can comment on or make changes to this bug.