Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS blank screen when opened from external app in 1.62+ #36026

Closed
iccub opened this issue Feb 13, 2024 · 7 comments
Closed

iOS blank screen when opened from external app in 1.62+ #36026

iccub opened this issue Feb 13, 2024 · 7 comments
Labels
bug OS/iOS Fixes related to iOS browser functionality priority/P2 A bad problem. We might uplift this to the next planned release. QA/Test-All-Platforms QA/Yes release-notes/include

Comments

@iccub
Copy link

iccub commented Feb 13, 2024

Description:

Steps to Reproduce

  1. Open an url from a 3rd party app

Actual result:

blank screen shows, the site does not load until you hit reload button

Expected result:

Reproduces how often: [Easily reproduced, Intermittent Issue]

Brave Version:

  • Can you reproduce this issue with the most recent build from TestFlight?
  • Can you reproduce this issue with the previous version of the current build from TestFlight?
  • Can you reproduce this issue with the current build from AppStore?

Device details:

Website problems only:

  • Does the issue resolve itself when disabling Brave Shields?
  • Is the issue reproducible on the latest version of Mobile Safari?

Additional Information

@iccub iccub added the OS/iOS Fixes related to iOS browser functionality label Feb 13, 2024
@cuba
Copy link

cuba commented Feb 16, 2024

When loading the default engine during startup on slow devices this may add an additional 10 seconds to load the first page. On newer devices this is more like 4-5 seconds. I'm not sure if this is the "white page" people are referring to. Certainly the screen is white during this period. But nothing "hangs" but rather adds a delay.

If we don't load this engine, anyone opening pages such as YouTube will encounter ads, trackers etc until they reload the page. (note for pages like YouTube, navigating will not fix this. A reload is necessary)

However there are some ideas out there which we will work on on how to deal with this delay:

  1. Using dat files during launch which seems to make compile times a little over 2x faster.
  2. If the above is not enough we might consider using a slimmed down version of the rules for launch purposes.

Note: We still don't even preload other filter lists such as cookie consent. Ideally we would preload all the enabled filter lists too so the user doesn't encounter things like cookie consent notices, open in app notices, etc during launch. But seeing as we are having launch problems with just the default filter list, this is unlikely to happen in the short run.

@iccub
Copy link
Author

iccub commented Feb 16, 2024

This happens when the app is foreground as well. We have at least 1 report with a recording showing app is running already

@cuba
Copy link

cuba commented Feb 16, 2024

Here are some usual launch metrics on an iPhone 8. Notice the ~9s launch delay which clearly (and intentionally) delays the first page load.
Screenshot 2024-02-16 at 10 09 35 AM

@cuba
Copy link

cuba commented Feb 16, 2024

This happens when the app is foreground as well. We have at least 1 report with a recording showing app is running already

Then i'm not sure if this is the cause of this issue. Not saying it's not Adblock related (I don't know) but something completely different than the launch tasks are casing it.

@cuba
Copy link

cuba commented Feb 16, 2024

Actually one possibility is that a newly updated filter list is downloaded and compiled during navigation. Notice how the additional filter lists still delay the subdocument page loads in the screenshot above. I can easily play with the priorities to make these downloaded tasks happen after the page load as seen here:
Screenshot 2024-02-16 at 10 32 53 AM

Notice how the subdocuments (decidePolicyFor:WKNavigationAction row) are loaded much faster and before the filterList(omo...) (compileEngine row) task

@mihaiplesa
Copy link
Contributor

mihaiplesa commented Mar 5, 2024

Happens to me and a friend as well.

@bsclifton bsclifton added the priority/P2 A bad problem. We might uplift this to the next planned release. label Mar 6, 2024
@iccub
Copy link
Author

iccub commented Mar 6, 2024

This is fixed and please give it a try in build 1.63 - not live yet in the app store.
brave/brave-core#22343

They delay Jacob mentions is separate issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug OS/iOS Fixes related to iOS browser functionality priority/P2 A bad problem. We might uplift this to the next planned release. QA/Test-All-Platforms QA/Yes release-notes/include
Projects
None yet
Development

No branches or pull requests

5 participants