Popup is sometimes unscrollable on iOS Safari

[StarScape]

Weird bug I've noticed a few times recently. Popup will let me scroll down partly, but then "sticks" at a certain point. The only place I'm sure this has happened to me is on reader.ttsu.app, though I can't remember for certain.

Here's a video:

output1.webm

And another, where I repro it several times:

output2.webm

I'll try to take a look at this if I get time, but want to make sure it's tracked

[birtles]

Thank you! Yeah, I'm not sure what that could be unless it's something funky in our scroll snapping (perhaps as a result of converting to Preact we messed something up there). Is this a new regression since 1.26.0?

[StarScape]

No, I can’t remember exactly when it started happening, but it definitely predates 1.26.0.

[jb-lopez]

I'm not sure if this is related, or if you want a separate issue. But, the scrolling doesn't work at all in Firefox.

It appears to be caused by the following div setup:

• The div with the class "content" has the style overflow:auto. This would work, but:
• div.content has a parent that has its exact same height. This makes overflow impossible (i.e.: client-height == scroll-height). The parent doesn't have a good way to reference it (it has a programmatic class set of class="tp:stacked tp:grow tp:has-overlay:[&>:first-child]:pointer-events-none tp:has-overlay:[&>:first-child]:starting:blur-none tp:has-overlay:[&>:first-child]:blur-[20px] tp:has-overlay:[&>:first-child]:[transition:filter_0.3s_ease-in-out]". So that must be the Preact shenanigans?

However, div.content's grandparent, div.window has a smaller height, therefore: If I open my inspector and put overflow:auto on div.content's parent, everything works as expected.

It looks like the extra div got added in the middle and messed up the scrolling. The overflow style just needs to be moved up to div.contents's parent, and I think that should work.

I'm using 1.26.0 on Firefox.

[birtles]

I'm not sure if this is related, or if you want a separate issue. But, the scrolling doesn't work at all in Firefox.

@jb-lopez Thanks for reporting this. Does this happen for you on all sites? And what platform are you on? Scrolling is working for me on Firefox using 1.26.0 on Windows.

I could well believe an extra div could mess things up—especially something that came about as part of refactoring to use Preact. However, I'd like to be able to reproduce the issue first. After that, we can try to work out if it's a separate issue.

[StarScape]

I hadn't tested this on Firefox before, but just confirmed that I cannot scroll on Firefox on macOS either.

[jb-lopez]

@jb-lopez Thanks for reporting this. Does this happen for you on all sites? And what platform are you on? Scrolling is working for me on Firefox using 1.26.0 on Windows.

This does seem to happen everywhere for me.

I've always used Firefox for Linux. Specifically Debian, and I've used the Firefox apt repo and not the Debian apt repo. (That is to say, the builds made by Mozilla and not by Debian.) I do not know if that makes any difference.

I know that I've always wanted more information in it (I'm the type that wants all the info I can get). Only recently did I notice that at the bottom was there cutoff text, leading me to look into it, and finding this issue.

---

To help out, here's some troubleshooting:

• I needed to find a page that I could use with text that would have a very long entry. I did find one. Today, at this moment NHK News Easy has the character で between two kanji compounds. (Now it's here so we can just use the で here.)
• I fired up a new profile in Firefox, with only this extension installed to eliminate the possibility that another extension is causing interference. The problem still exists in the new profile.
• I did not change any settings. Neither in Firefox nor in 10ten. I left everything as the default, just in case I was the one that did something strange to cause this. That didn't help.
• With the inspector open, if I hover over div.content you can see it's outline is much taller than div.container. (See screenshot.)

Since the extensions are in a shadow-DOM, Firefox creates a temp object so that I can reference it in the console.

Since the scrollHeight and clientHeight are the same, div.content won't scroll. There's another div between div.window and div.content that is also the same 1745 height.

Let me know if I can provide anymore info.

[birtles]

Thanks so much for all that info. I think I've worked out a distinction.

It looks like if when we collapse the list to show the top hits, scrolling works. In terms of the implementation that's when we add a fold point and collapse the window height to that size.

If we look up a word where there's no fold point (or where the initial matches fill the available space?) then scrolling doesn't work.

I suspect that's a regression—possibly from the (ongoing) Preact conversion work but I'll need to dig into it a bit more to be sure.

[birtles]

I started looking into this briefly today but I might need to pause for a moment so here's what I have so far:

• There are many permutations of containers we need to test
• It might be best to use this bug as motivation for finishing the Preact conversion so we can set up fixtures for all these permutations and test them

The outermost containers look like the following:

<div id="tenten-ja-window">
  <!-- #shadow-root -->
    <div class="container">
      <div class="window" data-type="window">
        <!-- Only rendered when tabs are enabled -->
        <div class="tab-bar"/>
        <!-- The following close-button-wrapper is only generated if there is
             NO tab bar enabled and there's a close button callback -->
        <div class="close-button-wrapper">
          <div data-type="overlay-container">
            <!-- If the overlay is showing it will be rendered here (Preact) -->
            <!-- The following status-bar-wrapper will only be generated if
                 there is a status bar -->
            <div class="status-bar-wrapper">
              <div class="content">
                <!-- When folded, the following scrolls and defines scroll
                     snapping -->
                <div class="expandable">
                  <!-- The following div is the host for our Preact rendering of
                       word entries -->
                  <div class="entry-data">
                    <div class="tp:flex">
                      <!-- First word entry -->
                      <div class="fold-point tp:contents" />
                      <!-- Remaining word entries -->
                    </div>
                  </div>
                  <button class="expand-button" />
                </div>
              </div>
            </div>
          </div>
        </div>
        <!-- Close button goes here when there's no tab bar -->
      </div>
    </div>
</div>

[birtles]

However, div.content's grandparent, div.window has a smaller height, therefore: If I open my inspector and put overflow:auto on div.content's parent, everything works as expected.

I think this is the core issue and I suspect it might come from refactoring I did to always include the overlay container back in af96d59 (where, ironically, I was trying to reduce the number of permutations of containers).

[birtles]

I found a minimal fix for this in #2722. I think it might fix the original issue but I'm not entirely sure. Certainly かけた will be affected but たてて does have a fold point, it's just that the window height will normally be shrunk before the fold point so maybe it's a variation on the same issue.