1906475 - Rendering issue with https://plugins.jetbrains.com/docs/marketplace/revenue-sharing-and-fees.html

Status: RESOLVED FIXED

(Core :: Layout: Scrolling and Overflow, defect)

Description

[jonathan]

Attachment: 2024-07-05 21-10-04.mkv

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

Steps to reproduce:

Visit https://plugins.jetbrains.com/docs/marketplace/revenue-sharing-and-fees.html, then scroll a bit.

Tested with Firefox on Windows 10 x64. I also tried with all extensions disabled.
Please note I did not face this issue in an Arch Linux VM.

Actual results:

The webpage content shakes. Please see attached screen recording.
Also, when it's shacking, pressing F12 does nothing. If I scroll up, it stops shaking, F12 opens the console, but I see no error or warning. If I scroll down again, it shakes.

Expected results:

The webpage content should not shake.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Timothy Nikkel (:tnikkel)]

Thanks for the report.

Did this start happening recently? Or did old versions have the problem?

Comment 3

[jonathan]

Old versions have the same problem. At least Firefox 126 and 125. Actually, I'm facing this issue since a while (months), but as only very few webpages at https://plugins.jetbrains.com/docs/ are affected, I did not take the time to raise an issue until today.

Comment 4

[Alice0775 White]

FWIW, disabling the following CSS will fix the issue.

https://resources.jetbrains.com/storage/help-app/v6/app.css

.table__wrapper--with-scroll {
overflow-x: auto;
}

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

This doesn't look like scrolling issues since if it's a scrolling issue the whole contents should be wobbled. I'd start with Layout:Tables.

Comment 7

[David Shin[:dshin]]

Hm, reminiscent of bug 1907289.
I unfortunately had problems reproducing that, no dice on reproducing this one either.
Reporter, does the bug still happen on release 128.0.2?

Comment 8

[jonathan]

(In reply to David Shin[:dshin] from comment #7)

Hm, reminiscent of bug 1907289.
I unfortunately had problems reproducing that, no dice on reproducing this one either.
Reporter, does the bug still happen on release 128.0.2?

For me, the bug is still present with release 128.0.2.

Comment 9

[David Shin[:dshin]]

Interesting, at least part of the reason why I can't repro is because the wrapper for the table receives table__wrapper--without-scroll for me, instead of table__wrapper--with-scroll. Putting that into the table in question generates the scrollbar, but doesn't cause the shaking behaviour.
It'd be nice if anyone who can reproduce this save the page ("Web page, complete").

Comment 10

[jonathan]

Attachment: Revenue sharing _ JetBrains Marketplace Documentation.zip

Comment 11

[jonathan]

(In reply to David Shin[:dshin] from comment #9)

Interesting, at least part of the reason why I can't repro is because the wrapper for the table receives table__wrapper--without-scroll for me, instead of table__wrapper--with-scroll. Putting that into the table in question generates the scrollbar, but doesn't cause the shaking behaviour.
It'd be nice if anyone who can reproduce this save the page ("Web page, complete").

Sure: attached Revenue sharing _ JetBrains Marketplace Documentation.zip

Comment 12

[Gregory Pappas [:gregp]]

I can reproduce on Linux by zooming the page 110%. Note that it only reproduces when 'Always show scrollbars' is enabled in about:preferences

Got bug 1825384 as the cause with mozregression. This contradicts comment 3 which says the issue has been present since 126/125.

Reporter, please consider using mozregression to find out which version introduced the problem for you

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Just wondering whether it's fixed by setting "layout.scroll.disable-pixel-alignment" to true in about:config.

Comment 14

[jonathan]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

Just wondering whether it's fixed by setting "layout.scroll.disable-pixel-alignment" to true in about:config.

I tried, but it changed nothing.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

So their code is doing something very weird. They have a setup similar to this:

<!doctype html>
<p>Do you see scrollbars below?</p>
<div style="overflow: auto; width: 500px; height: 500px;">
  <table style="width: auto; height: 300px; margin: -1px; clip-path: inset(1px);"></table>
</div>

Except they add or remove the overflow: auto dynamically based on something, and they're getting into a loop thinking they need scrollbars when they don't and then vice versa.

They don't have source maps and their codebase is a react app so it'd be great to get some feedback from them to know what are they using...

My guess is they might be using Element.client{Width,Height}, which round and thus are prone to fractional issues like these in some systems / at some zoom levels... But would be great to confirm that's the case.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

The other issue is that I think they try to rely on that clip-path to not cause overflow, but that's not the case per spec. They could use overflow: clip and overflow-clip-margin instead to achieve the effect they want...

Comment 17

[jonathan]

Just for info, I also opened an issue on JetBrains' bugtracker, if you want to discuss with them: https://youtrack.jetbrains.com/issue/MP-6715/Rendering-issues-with-Firefox

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Thanks! I had just tried to contact them in the email at the bottom of the page.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

I commented there as well.

Comment 20

[Jonathan Kew [:jfkthame]]

Attachment: [macOS/Safari] Screen Recording 2024-08-05 at 12.50.21.mov

A somewhat related issue can be reproduced in Safari, too, as seen in this screen recording. Note how the horizontal scrollbar under the table appears and disappears as the window is resized horizontally.
(But I didn't manage to find a state where it got into a continuous loop while the window size is static, as seen in the Firefox issue, so it's more of a transient annoyance while actively resizing.)

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reduced test-case.

This seems to be due to how we compute scroll{Width,Height} for overflow: visible elements. The mix of the border and the negative margin causes us to return a different result (a higher scroll margin). With the right content you can trick their logic.

In the page both the border and the margin are 1px and -1px rather than 10, which made it rather trickier to find...

I'm still not quite sure what the right answer is here tho. I think per https://drafts.csswg.org/cssom-view/#dom-element-scrollwidth we're doing the right thing, but of course calling that a "scrolling area" seems funny.

WebKit's implementation is here, Blink's is here.

It makes some sense to clamp to the client rect I guess, since it matches what it'd return if you were scrollable?

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1906475 - Improve scroll{Width,Height} implementation for overflow: visible frames. r=#layout

Comment 23

[Emilio Cobos Álvarez (:emilio)]

https://treeherder.mozilla.org/jobs?repo=try&revision=fddbcfbac858477a4d502f38dbfac69401dd3554

Comment 24

[Timothy Nikkel (:tnikkel)]

Is this something where we'd want to open a spec issue to get it improved for the future?

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Yes, I thought of doing that, but then realized that the spec says (if I'm not wrong) that WebKit / blink is correct: https://drafts.csswg.org/cssom-view/#scrolling-area for an element says the left edge of the "scrolling area" is the left padding edge (thus that we should ignore the left margin and the border).

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8d836e6ec98a
Improve scroll{Width,Height} implementation for overflow: visible frames. r=dholbert

Comment 27

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/47619 for changes under testing/web-platform/tests

Comment 28

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/8d836e6ec98a

Comment 29

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 30

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

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

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

For more information, please visit BugBot documentation.

Comment 32

[Emilio Cobos Álvarez (:emilio)]

This feels rather risky to uplift.