No automatic horizontal scrolling in multi-line selection mode

[matthieu-m]

Behavior

On the playground, multi-cursor selection is supported with the ALT key being pressed. For example, given the following (invalid) Rust code:

impl X {
    fn foo() {
        let sql =
            u"SELECT
            u"    COALESCE(acquisitions.month, investments.month) AS month,
            u"    acquisitions.companies_acquired,
            u"    investments.companies_rec_investment
            u" FROM (
            u"    SELECT
            u"        acquired_month AS month,
            u"        COUNT(DISTINCT company_permalink) AS companies_acquired
            u"    FROM tutorial.crunchbase_acquisitions
            u"    GROUP BY 1
            u") acquisitions
            u"FULL JOIN (
            u"    SELECT
            u"        funded_month AS month,
            u"        COUNT(DISTINCT company_permalink) AS companies_rec_investment
            u"    FROM tutorial.crunchbase_investments
            u"    GROUP BY 1
            u")investments
            u"ON acquisitions.month = investments.month
            u"ORDER BY 1 DESC
            u";
            u"
    }
}

One can place the cursor right before SELECT, press ALT, and drag the mouse down and to the right, selecting the SQL query without any leading u".

If dragging the mouse further than the boundary of the text box -- for example because the "run" panel is present -- the text within the text box does not scroll horizontally. Instead, the mouse pointer will slide to be over the right-hand panel.

Surprisingly, the text beyond the edge of the text box is still selected, and can be copy/pasted.

Expectation

Multi-cursor selection works just like regular selection, and the text within the text box scrolls horizontally to keep the current position of the pointer visible.

Details

OS: Windows 11
Browser: Firefox 139.0.4 (64-bit)

[shepmaster]

I think you will need to provide more information...

"Works on my machine!" (macOS, Safari, Ace editor)

[matthieu-m]

Edited the description to include that the behavior occurs on Firefox 139.0.4 on Windows 11.

[shepmaster]

"Works on my other machine!" (Windows 11 Pro (26100.4202), Firefox 139.0.1, Ace editor)

Recording.mp4

[matthieu-m]

I tried playing around some more, and I manage to reproduce both your behaviour... and mine!

It appears that horizontal scrolling only works if the pointer is on an overflowing line.

However, if you start block-selecting (with minimal width selection), and then move the pointer right on, say, the ORDER BY 1 DESC line, then horizontal scrolling doesn't work, and the pointer ends up hovering over the right-hand panel.

If then, still hovering over the right-hand panel, you move the pointer up next to the COUNT(DISTINCT company_permalink) AS companies_rec_investment, suddenly the left-hand panel scrolls horizontally so the end of this line appears, while the pointer remains over the right-hand panel.

[shepmaster]

Do you see the same problem if you use Ace directly at their kitchen sink? If so, I think this will be more of an upstream issue.

[matthieu-m]

Yes, it's reproducible there.

In the absence of a side panel there, I simply used a narrow browser window.

I note that horizontal scrolling happens in both direction:

• Put the pointer at the level of a very long line (from outside the window) and the window scrolls to the right as much as possible.
• Put the pointer back at the level of a very short line (whose end is now invisible) and the window scrolls back to the left to show the cursor on that line.

So whether it's a bug or not may belong in the eye of the beholder, in the end.

[shepmaster]

Yes, it's reproducible there.

[...]

So whether it's a bug or not may belong in the eye of the beholder, in the end.

I'll leave it up to you to decide, but if you want to take it further, this sounds like something that you'd need to take up with the Ace crew. If you do, feel free to link to the issues on their repo from here so I can keep abreast of the outcome.

[matthieu-m]

I've opened ajaxorg/ace#5836 (as already cross-referenced above).

Let's see what UI specialists think about it... I'm personally not convinced there's a good (simple) solution, so not clear anything will come out of it.