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
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
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.
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?
(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).
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
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.
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.
Inspector bug triage (filter on CLIMBING SHOES).