Webview positioned partially offscreen hides content

[sanogueralorenzo]

Describe the bug Any drawing app scrolls up and down while drawing. Possibly related to https://github.com/duckduckgo/Android/pull/674 makes DDG completely unusable in this matter.

How to Reproduce Steps to reproduce the behavior:

1. Go to https://sketch.io/sketchpad/
2. Try to draw anything
3. See error

Expected behavior Drawing should be able to work on any webpage with drawing canvas capabilities, coordinator layout should stop going up and down while you are drawing, making drawing impossible

Smartphone (please complete the following information):

• DDG App Version: 5.62.0 zk (been there at least since I started using it half a year
• Device: All phones
• OS: All OS

[cmonfortep]

Thanks for reporting and sharing that website as an example. We knew about websites having bottom-anchored content being affected, but this one is a different and totally valid use case too.

Related: https://github.com/duckduckgo/Android/issues/638

[kwawmannanjnr]

I'm new to contributing to opensource projects. Can I work on this issue?

[subsymbolic]

@kwawmannanjnr definitely, we welcome PRs for any issues tagged with help wanted. Check out our CONTRIBUTING.md guidelines for more information.

[cmonfortep]

Information for possible contributions: The issue is that the web view can actually off be positioned partially offscreen depending on the scrolling. When you scroll the page, the toolbar slides up, as does the web view. So only when the toolbar is fully up off screen is the web view fully positioned onscreen. It seems to be a combo of the scroll behaviour + CoordinatorLayout that is causing the issue.

Some websites where this issue is easy to reproduce are:

• twitter.com -> Bottom bar is hidden and user needs to scroll to make it appear. Expectation is that bottom bar is visible always.
• https://sketch.io/sketchpad/ -> as described in the description

[garygreen]

@cmonfortep if this issue is one that's "different and totally valid use case too" then why did you close #638 ? This issue looks complex and different the one described in that other issue. The complexity of trying to fix the sketchpad app vs bottom navbar / fixed position elements generally is a different issue imo.

[cmonfortep]

Hi @garygreen, by "this one is different" I didn't want to say it's another problem, but a new scenario that we didn't know about. Both issues are affected by the same root cause.

I understand your point here, however, we didn't want to keep both issues open and decided to give this one more visibility during Hacktoberfest. I apologize if that was not clear.

In any case, we also posted this comment, which explains the root cause, and also shares the examples we commented in https://github.com/duckduckgo/Android/issues/638

[cmonfortep]

Tracking this internally: https://app.asana.com/0/0/1187616573788673/f

[tvalle]

Are you guys fixing this internally or could I try to tackle this?

[cmonfortep]

Go for it! We are tracking this issue internally, but we haven't had time to work on that yet.

[tvalle]

Unfortunately I couldn't understand what's the cause of this issue so I couldn't provide a fix. I'll try another issue to fix.

But while experimenting and trying to understand what's going I saw this behaviour: if in fragment_browser_tab.xml one sets android:fitsSystemWindows="true" on the root CoordinatorLayout and then set android:layout_marginBottom="?attr/actionBarSize" in the ConstraintLayout with id browserLayout everything works properly (sketchpad and Twitter) but the swipe up on the AppBarLayout stops working. Maybe because fitsSystemWindows interferes with the CoordinatorLayout behaviors. I know this is not a fix but maybe is a helpful tip for someone who might fix this.

[ryg-git]

If it is ok, I would like to work on this issue

[kolanse]

Please is this issue still open to be tackled?

[marcuswu]

The above commit is unfortunately not a solution. I'm not convinced this is the right approach for a few reasons listed below, but it could be on the right track.

• I am not 100% sure this isn't possible without subclassing AppBarLayout.ScrollingViewBehavior. That behavior does adjust positioning, but I haven't found where it or its parent alters view size. I haven't exhausted the search, but if the behavior can do that, it'd be best to use its ability to do so. Layout Inspector showed me that for everything else I tried, the FrameLayout that contains the WebView is the same size as the CoordinatorLayout and is pushed down by the AppBar, clipping the bottom of the FrameLayout and therefore the WebView
• sketch.io still scrolls while drawing and the AppBar still hides. This is likely because my solution uses padding instead of resizing the view which means the FrameLayout is still larger than the viewable area when the AppBar is visible. My attempts at actually resizing the view performed worse (jittery movement)
• The web page layout of twitter.com looks incorrect when scrolling is first initiated, but returns to what's expected during the scroll. I noticed that other Android browsers behave the same way, but seem to correct it faster than this. This performance difference could be due to running a debug build.

I went ahead and committed my work and pushed it up to a fork in case it furthers discussion on an actual solution.

[marcuswu]

I've iterated over my earlier code and have what I believe to be a working solution. I'd love some feedback.

[oldergod]

Why not taking into account the height of the navigation bar?

[ChiefORZ]

@marcuswu could you just please open a Pull Request with your fix. This fix needs attention - nobody cares about it -.-

[marcuswu]

I am not convinced my solution was ever really 100% correct. I did open a PR for it, but it was closed because it was supposed to be working properly on the latest code. I would look again, but I have some other projects taking my time right now.

[mohammadreza-torkaman]

Hey, I'd like to contribute. can I work on this issue? Does this still need help?

[AndroidPoet]

I I'd like to fix this.

[nb1987]

Just chiming in to provide another example where this behavior is easily reproducible:

http://szimek.github.io/signature_pad/

We are leveraging the SignaturePad library in one of our projects, but this issue has meant we have to recommend our DuckDuckGo users to switch to Chrome.

[MohitMandalia]

Seems it might be resolved with the latest version of dev:

Tried it with version 5.138.1 on below devices with Android 13

• Google Pixel 4a
• Google Pixel 5a

[malmstein]

Closing this stall issue. This doesn’t apply anymore.

[StampixSMO]

Not sure why this was closed, this is still very relevant and still appearing on versions > 5.138.1