www.kijiji.ca - Unable to type a reply message

[webcompat-bot]

URL: https://www.kijiji.ca/m-msg-my-messages/conversation/kg0:gcqr6d:2dw0r8g9k

Browser / Version: Firefox Mobile 79.0 Operating System: Android Tested Another Browser: Yes Chrome

Problem type: Site is not usable Description: Missing items Steps to Reproduce: No dialog to write message, works in Chrome

Browser Configuration

• gfx.webrender.all: false
• gfx.webrender.blob-images: true
• gfx.webrender.enabled: false
• image.mem.shared: true
• buildID: 20200629163142
• channel: beta
• hasTouchScreen: true

From webcompat.com with ❤️

[softvision-oana-arbuzov]

Thanks for the report, but I get an error message when navigating to the provided URL, both on Firefox and Chrome.

Note: I've search for some products and started a conversation with the seller, and I can send him a message without any issues. URL: https://www.kijiji.ca/v-heating-cooling-air/pembroke/central-air-conditioning-cleaning/1497044955

After sending the message and when he replied, there was no way to type in the message, since the address bar was blocking the chat.

Note: The issue is not reproducible on Firefox Release and Chrome.

Tested with: Browser / Version: Firefox Preview Nightly 200706 (🦎 80.0a1-20200702094606) Operating System: Huawei P20 Lite (Android 8.0.0) - 1080 x 2280 pixels, 19:9 ratio (~432 ppi density)

Moving to Needsdiagnosis for further investigation.

[karlcow]

So on rdm obviously because there is no visible address bar on the viewport area, there is no covering.

but the body is set with min-height: 100vh

html, body {
    display: flex;
    flex-direction: column;
}
body {
    overflow-x: hidden;
    -moz-osx-font-smoothing: grayscale;
    -webkit-font-smoothing: antialiased;
    -webkit-text-size-adjust: 100%;
    -moz-text-size-adjust: none;
    -ms-text-size-adjust: 100%;
    min-height: 100vh;
}

and

<meta name="viewport" content="width=device-width, initial-scale=1.0">

[karlcow]

ah I think I understood. Both chrome and firefox receives the same thing and behaves the same way. But the site is coded in a way that they think the toolbar is always at the top so they push the center part by adding a top padding of 63px to give room.

html#reset .fes-pagelet .messageList-1007444790 {
    padding: 63px 20px 10px;
    padding-top: 63px;
    padding-right: 20px;
    padding-bottom: 10px;
    padding-left: 20px;
    box-sizing: border-box;
    display: flex;
    flex-direction: column;
    justify-content: flex-end;
    min-height: 100%;
}

and the top menu is set with

html#reset .fes-pagelet .messageListHeaderContainer-138926881 {
    position: fixed;
    top: 0;
    width: 100%;
    z-index: 1;
}

In chrome:

1. The top 0 here doesn't at the top of the viewport, but below the addressbar in chrome BEFORE scrolling.
2. As soon as I scroll the down and then scroll up, the addressbar goes into hiding AND suddenly the height is higher than the 100vh. the new scrollable area of the full content is now height of the dynamic addressbar + the height of the viewport.

[karlcow]

but because it involves also flexbox I wonder if there is an interaction here too because the central part of the content is always align with the top of the screen dynamic toolbar or not.

[karlcow]

having a test case for this would be probably useful.

[denschub]

That's an unfortunate issue. The hidden overflow and the use of 100vh on this site runs into an issue we've been having for a while. Fenix' bottom scrollbar is "covering up" parts of the content, and there is no way to get to it.

There is a Fenix issue (https://github.com/mozilla-mobile/fenix/issues/14839) and a corresponding layout issue (bug 1663634), but unfortunately there isn't even a great workaround to suggest here that would solve that in this case.

Closing this as a duplicate of aforementioned bugzilla bug, which is the best thing I can do. I have, however, increased the webcompat-priority of that bug, so maybe there will be some movement in not too distant future.

[webcompat-bot]

Generate outreach template

[denschub]

Let's try to reach out to them.

[karlcow]

I wonder if @lucaslim and @mgpcoe from @KijijiCA could help us find the right person for this issue. Mozilla is trying to understand the motivation the overflow: hidden but want to have reachable contents initially obscured by the dynamic toolbar.

There is an issue opened on Bugzilla for it, but before taking any decision on fixing we need to understand what was the intent.

[mgpcoe]

Hi @karlcow, thanks for bringing this to our attention! We're going to assign some developer time to investigate what can be done on our end to work around this problem. It looks like a bit of an edge case, because the user has to set their toolbar location to the bottom of the screen in order to induce it. On the plus side, though, that makes it reliably reproducible.

As to why we'd set a global overflow: hidden, we tend to include floating UI elements on the page. In the case of this page, that includes some information about the ad being discussed and the other person you're chatting with; you can see that in the screenshots that were attached, where part of the ad title, the lead picture, and the price are visible at the top of the screen. These hover persistently so that, when you're several messages deep in a conversation, and open the "new message" alert from your email, that context is available while you're reading the most recent message.

[hiikezoe]

@mgpcoe thanks for the reply! I am a Firefox engineer who've been trying to match our behavior Chrome and Safari in this kinds of mobile viewport related issues.

One thing I am really interested in is whether web author who are specifying overflow:hidden on the root element with height:100vh expect browsers move the dynamic toolbar to make initially overflow-ed contents visible? In other words web authors expect there are possibly some contents initially covered by the toolbar with overflow:hidden and height:100vh? In my understandings, web authors specify overflow:hidden to cut-off such overflow-ed region. And it looks to me that in the Kijii's case min-height: 100vh on body element is not necessary. What's the intention behind the properly?

[m4ttyng]

@hiikezoe Hey there! I've been assigned at Kijiji to fix this issue on our end. Just wanted to clarify something first as to your question. We in fact do not set overflow:hidden on the root element with height:100vh . If you look at the code sample provided above more closely, we set overflow-x: hidden. The real issue here is we are not position fixing the bottom send message bar to the actualy bottom of the viewport. Even with the browser toolbar on the top, the send message bar is hidden initially and you have to scroll down to it.

As to why this is setup like this now... I'm not too sure :P but I will be working to fix this issue.

[hiikezoe]

Thanks for pointing it out. You are right. I should have looked the code carefully. I did check that overflow-x:hidden with height: 100vh works as expected, in other words, it moves the dynamic toolbar. It looks this case is totally different from what I filed before (bug 1663634).

I filed a new bug (bug 1717374).