Project

General

Profile

Actions

Bug #1171

open

background open doesn't work after used once per tab

Added by ask low 10 months ago. Updated 9 months ago.

Status:
New
Priority:
3.x
Start date:
02/21/2024
Due date:
% Done:

0%

Estimated time:

Files

background-open-issue.mp4 (6.05 MB) background-open-issue.mp4 ask low, 02/21/2024 07:22 AM
drag-n-drop.mp4 (4.41 MB) drag-n-drop.mp4 ask low, 02/23/2024 08:44 AM
Actions #1

Updated by ask low 10 months ago

After using the "open in background" once in a tab, it doesn't work the next time, unless the tab is switched back & forth.

version: 3.17 (standard fdroid)

Actions #2

Updated by ask low 10 months ago

  • Priority changed from Critical Bug to 3.x
Actions #3

Updated by Soren Stoutner 10 months ago

My experience is that this is actually on of the WebView bugs introduced with Android 14. Specifically, it appears to be something to do with the way the WebView is processing inputs. It tends to affect some websites much more than others, lending me to think it might be related to the JavaScript that is being processed. For example, I personally find it happens a lot with https://www.deseret.com/.

When I experience this problem it is often after a scroll event is incorrectly detected as a fling, which is then over processed (it scrolls massively fast to the bottom of a page). After that, it doesn't process touch events correctly (long-pressing on a link doesn't pull up the context menu). Of all the thing I have tried to fix this, the only thing that has worked so far is moving the WebView off the screen by switching to another tab and then switching back. My guess is that a bunch of logic is run whenever the view is hidden and then redisplayed that corrects whatever has become confused in WebView's touch processing.

There doesn't appear to be anything I can do to fix this problem, but I expect Google to fix it in a future WebView update. It might be fixed at the same time as Bug #1106: New intents sometimes aren't loaded on restart on Android 14 (WebView crash). They might even have the same underlying cause.

Actions #4

Updated by ask low 10 months ago

Yes this is the recent issue I've been facing. On both FOSS Browser & PB. But FOSSB prioritises context menu before drag & dropping links. Here in PB, it turns into drag n drop instead of context menu.

Actions #5

Updated by Soren Stoutner 9 months ago

I'm not sure what you mean by drag and drop.

Actions #6

Updated by ask low 9 months ago

When the 2nd trial for bringing context menu, that's where it turns into another feature where you can drag & drop the link to some other place. I believe this has to do something with tablets or a desktop browser thing.

Actions #7

Updated by Soren Stoutner 9 months ago

That's interesting because it is not how my device behaves. Regardless, it appears to be fully a problem with WebView than can only be fixed by an update to their code.

Actions #8

Updated by ask low 9 months ago

This is the thing that I'm talking about

Actions #9

Updated by Soren Stoutner 9 months ago

That's interesting. It's not how my device behaves. If I thought there was something I could do about it I would try to narrow down why it is different for you than for me, but because I can't do anything about it I would rather spend the time on more fruitful endeavors.

Actions #10

Updated by ask low 9 months ago

Sure. Don't worry about this I guess. If it's webview issue I think it'll get fixed by itself on further updates.

Actions

Also available in: Atom PDF