Gatsby: [www] twitter ios nav bar overlaps ours

[KyleAMathews]

• https://twitter.com/rchrdnsh/status/1038260112467484672
• https://twitter.com/rchrdnsh/status/1038260324174970881

[rchrdnsh]

Yay! I made a good first issue :-)

I’ve noticed this behavior in iOS Safari in general on other sites as well, although Gatsbyjs.org seems to be ok there, at least for me. Might be a WebKit bug?

[07Gond]

Maybe we can specify the version and model of iPhone and iOS?
I tried this on iPhone 7 & 8 and everything is ok.

[code4cake]

I could take this issue, if no one is working on it :)

[07Gond]

@dantesolis Did you reproduce the bug? I can't.

[rchrdnsh]

apologies, it’s an iPhone X running iOS 11.4.1.

[code4cake]

@07Gond I hadn’t I just saw the issue was open and wanted to give it a try. I’ll try to reproduce the issue. Thanks @rchrdnsh.

[fk]

That'd be great @dantesolis! 🙏

[code4cake]

hey guys, quick update. I'm currently working on this issue.

[07Gond]

Post here any update or if you need help 💪

[code4cake]

@07Gond I actually had a question, how could I "force" that twitter navigation bar? should I mock another component or something like that? Thanks

[07Gond]

Hi! @dantesolis
I was thinking about doing some simple swift code to run on a WKWebView that URL.
I just tried that but with the iOS 12 simulator.

• The fixed position of that bar is not respected:
  
• If you scroll down to the bottom you can see the bar:
  

I don't have an iPhone X so, I don't know if the device with iOS12 has the same behavior.
About the replication of the error in this issue maybe you can try the same but with an iOS 11.4 simulator. Maybe that issue is only visible on that version or maybe we have to do more for the replication.

[gurtjun]

Found a similar issue when browsing https://gatsbyjs.org using Safari. This should be fixed in #9449.
But I don't think this will fix this issue. 😞

[Saifadin]

Is someone working on this, or is it open?

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[code4cake]

Hey guys, question. Is this still open? I was working on it. But then got sidetracked 🙃 , but don't know if it's still open and not solved ? If so I'll take (again) if possible 😄

[fk]

Hey @dantesolis! I _think_ this is still open, but I don't have the things needed to test myself right now. :( Could you do that?

I'll remove the stale label from the issue for now.

[code4cake]

@fk will do. Thanks man ;)

[fk]

@dantesolis Yay! Thank _you_! 🤗

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[code4cake]

not stale working on it 😄

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[code4cake]

not stale, fuudge why does time passes so quickly ??? gonna push tis weekend or latest end of next week. Have been hammered at work
Thanks and sorry for the delay

[ghost]

@dantesolis any progress on this? If you're not working on it. I would like to help out!

[code4cake]

@laurosilvacom to tell you the truth I have been hammered 🔨 at work lately so haven't had time to look at it, was about to start working on it, but help is always welcome. Have you made any progress thus far ?

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[PatrickLambert1101]

Hey guys can I grab this issue?

@dantesolis did you make any progress?

[code4cake]

@PatrickLambert1101 feel free to take it, cause I've been hammered at work lately and now is just sitting here. Sorry for the not following through folks.

[PatrickLambert1101]

Awesome! Thanks, could someone please assign it to me

[lannonbr]

@PatrickLambert1101 So I can't assign you using GitHub's assign feature, but I can mark that this issue has been assigned and they can read through this that you wish to work on this.

[michaelneu]

@PatrickLambert1101 are you still working on this? I did some research and there are two issues with the current tab bar:

1) padding-bottom: env(safe-area-inset-bottom) is overwritten by setting the height to a fixed value. The safe area on the iPhone X (or newer) isn't respected, thus the tab bar is put straight to the bottom.

Removing the height using the Safari devtools seems to work on my iPhone XR. Adding transition: padding-bottom 0.2s smooths the transition a bit on Safari.

2) Twitter's WKWebView apparently doesn't update safe-area-inset-bottom and generally overlaps the viewport. I used this test page:

<!doctype html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  </head>
  <body>
    <div style="position: fixed; bottom: 0px; left: 0px; right: 0px;">
      <div style="height: 34px; background-color: red;"></div>
      <div id="spacer" style="height: env(safe-area-inset-bottom); background-color: black;"></div>
    </div>

    <div class="size"></div>
    <div style="height: 1000px;"></div>
    <div class="size"></div>
    <div style="height: 1000px;"></div>

    <script type="text/javascript">
      function updateSizeLabel() {
        const spacer = document.querySelector("#spacer");

        document
          .querySelectorAll(".size")
          .forEach((x) => x.innerHTML = `
            inner window height: ${window.innerWidth}x${window.innerHeight}
            <br />
            outer window height: ${window.outerWidth}x${window.outerHeight}
            <br />
            spacer height: ${spacer.getBoundingClientRect().height}px
          `);
      }

      updateSizeLabel();
      window.addEventListener("resize", updateSizeLabel);
    </script>
  </body>
</html>

When scrolling in Safari, the spacer height updates to 34px whenever the tab bar is hidden. However, in Twitter's browser it stays at 0px. As far as my test goes, it seems like those 34px padding are required to not be hidden by Twitter's tab bar, as I suspect this is happening:

Detecting and correctly calculating the padding for Twitter's browser could be difficult, as the viewport doesn't know it's behind something else. The only "solution" I can think of is always having padding-bottom: 34px, so the overlap can safely be ignored. I don't really like this, as it steals screen space, but it would at least prevent Twitter's UI hiding the tab bar.

Also, hard-coding this for Twitter wouldn't be a good idea IMO. The only way (I tried) to find out whether the page was opened in the Twitter browser is to check the document.referrer, which could be t.co - but this is also the case when opening the page in the browser using the bottom right button. Furthermore, listening for the window resize event doesn't feel right either, even if you _could_ detect the Twitter browser this way.

So, as far as my research goes, there are two ways to solve this at the moment (unless Twitter decides to fix this themselves):

• ignore it for the Twitter browser and just use env(safe-area-inset-bottom) to fix it in Safari
• always add a padding of >= 34px to the bottom

If you're not working on this @PatrickLambert1101, I'd like to take over and implement whatever the consensus will be.

[sidharthachatterjee]

This doesn't seem to be an issue anymore, as evidenced on my iPhone 11 Pro Max in both Safari as well as the Twitter web view

Closing this as a result! Thank you everyone 💪

[fk]

Ahh nice, thanks @sidharthachatterjee! 🙏
This made me realize I now have such a phone, too, so I got curious — minor problems remain:

(^ Opening a link to gatsbyjs.org from within the Twitter app, opening the sidebar navigation with the Twitter navbar hidden; if the Twitter navbar is visible, things are fine)