2

I have searched a lot and havent found any solution that works so here it is.

I have created a button that is after the content and have applied css for it to become sticky at the bottom of the page...

<button class="ocs-trigger ocs-toggle ocs-toggle-posts-toc-mobile">Περιεχόμενα</button>

button.ocs-toggle-posts-toc-mobile {
  display: block;
  bottom: 10px;
  position: sticky;
  position: -webkit-sticky;
  margin: auto;
  border-radius: 4px;
  box-shadow: 0 0 3px 0 #d5d5d5;
  background: #232f3e;
  font-weight: 500;
  font-size: 18px;
  padding: 7px 12px;
}

It works everywhere in any browser i tested except mozilla android. If mozilla bottom adressbar is visible the button works okay. https://i.stack.imgur.com/kAoyw.jpg

BUT if mozilla’s bottom address bar is hidden, the button isnt clickable. https://i.stack.imgur.com/EuGlj.jpg

When the mozilla’s bottom address bar is hidden i think the viewport height changes, and maybe because the button is now where the visible adressbar was maybe it out of the "active" viewport of mozilla... that's definetely a bug i believe cause it doesnt happen in other browsers!

Nevertheless can you take a look and see if i have anything i have missed?

I would really appreciate it cause i have looked almost everywhere i believe...

test url: https://thefinterest.kinsta.cloud/p/asjalska/

John Aps
  • 63
  • 5
  • I tried the URL in my mobile FF and I can confirm the unclickable button. After some research, I found an open issue which is somehow related to this faulty behavior: https://github.com/mozilla-mobile/fenix/issues/13797 – gru Jan 28 '22 at 12:36
  • Have you tried experimenting with the `z-index`? – gru Jan 28 '22 at 12:39
  • Yes z-index is something i tried but to no avail... – John Aps Jan 28 '22 at 12:47
  • I have seen this issue but it isnt exactly the same, he is saying about a problem when the adressbar is visible, i have a problem when the adressbar is hidden! – John Aps Jan 28 '22 at 12:48
  • I still think it's related, I guess there is some space reserved/blocked at the bottom, no matter if the bar is displayed or hidden. – gru Jan 28 '22 at 15:24
  • Let me check that again. – gru Jan 28 '22 at 15:25
  • I started documenting my investigations in an answer, still work in progress. – gru Jan 28 '22 at 16:42

1 Answers1

2

Investigations using Firefox remote debugging

TL;DR: With high probability a bug in the Firefox mobile app

So I've linked up my phone to the computer and started a remote debugging session on the page you provided.

When inspecting the button element <button class="ocs-trigger ocs-toggle ocs-toggle-posts-toc-mobile">Περιεχόμενα</button> we can see the exact box position highlighted in the viewport: screenshot

And now it gets interesting. Apparently, the DOM box of the element gets shifted as soon as the bottom bar disappears. Or rather: The initial viewport (when the bottom bar is visible) doesn't change, because the box is still located at the same position.

So you can in fact still click/touch the button but in an area above it.

You can see this behavior in the screen recording below:

screen recording of incorrect scrolling behavior

Cookie banner is repositioned as expected

Interestingly, the behavior of the cookie banner (hidden in the screen recording because already confirmed) looks as expected though. So what's the difference to the button?

screen recording of correct behavior of cookie banner

Workaround and working solution: move the button above the #ocs-site element

Apparently, after quite a lot of experiments, I realized the only difference between the button (incorrect behavior) and cookie banner (correct behavior) is the fact, that the cookie banner is in a rather top level of the DOM, whereas the button is nested quite deep in the tree.

Finally, I could find a working solution that makes the button behave as expected. Here you can see the correct scrolling behavior:

screenrecording of fixed scrolling behavior

The solution I've come up with is to move the .ocs-trigger button above the #ocs-site div element. This fixes the incorrect scrolling behavior when the bottom bar disappears/appears.

Also, apply some styles on the .ocs-trigger element for the correct positioning.

position: fixed;
bottom: 10px;
z-index: 11;
left: 0;
right: 0;

Here you see the final DOM in a screenshot:

screenshot of the final DOM including styles

Please note, that you probably have to apply additional styling changes. This solution's major aspect was to get rid of the incorrect scrolling behavior.

Follow-up: Firefox Bug? Seems to me.

As it still appears to me at this moment, I would say this is a bug in the mobile Firefox implementation. My guess is, that the viewport calculations are somehow incorrect for nested elements.

In order to get some attention on this topic, I would recommend you to share these investigations and documentation with the Mozilla team at https://github.com/mozilla-mobile/fenix/issues. Let me know if I can help you with this.

gru
  • 2,319
  • 6
  • 24
  • 39
  • you are very right! i had also myself used android remote mozilla debugging and saw that behavior but didnt associate it the right way! I will try again to see if this is fixed with a resize event listener by fixing the position with css... I am waiting your input as well! Thank you very much for your time!! – John Aps Jan 28 '22 at 16:49
  • i used remote debugging and tried some css, but this seems to be actually a firefox bug as you already suggested... did you came to the same conclusion? Or maybe, is there anything else you may have thought of to overide this behavior? – John Aps Jan 28 '22 at 18:17
  • I would recommend experimenting with the `onResize` event (with some throttling). maybe the button can be re-aligned correctly when the size changes. – gru Jan 28 '22 at 21:10
  • let me know if you make any progress in the meantime, I will get back to it tomorrow. – gru Jan 28 '22 at 21:12
  • i tried using simple css positioning but it doesnt work... because it simply changes both the actual button position and the "shadow" button's position... show i am stale... maybe if there is nothing we can do, i will post it in bugzilla in that thread... i will try a few more things though and get back! – John Aps Jan 28 '22 at 21:23
  • interestingly, the cookie banner (invisible) is repositioned with the viewport changes as expected! see the updated answer. – gru Jan 30 '22 at 18:11
  • alright, so I'm done with the investigations and I could find a solution to get rid of the incorrect scrolling behavior. check out the answer again. – gru Jan 30 '22 at 19:27
  • regarding the (presumable) bug, this should be reported to Mozilla, as described in the answer. – gru Jan 30 '22 at 19:28
  • Have you made any further actions here? – gru Feb 01 '22 at 20:13
  • 1
    Thank you very much gru for all your work, you are really a delicate man and i appreciate that! I reported the problem to mozilla and they got back to me... Until then i will check out your solution for moving the element further up inside the html, i of course accepted your answer and i am most welcome! – John Aps Feb 02 '22 at 19:04