-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
[wasm] Blazor: CSB randomly does not work on iOS #16144
Comments
From @SteveSandersonMS on Friday, August 9, 2019 9:34:08 AM
That is expected, since the iOS simulator doesn't support WebAssembly. @mkArtakMSFT We should move this issue to the |
Tested iPhone X & iPad Pro wth iOS 13 (17A5556d)... Neither device are developer unlocked and are running the most recent public iOS 13 beta... Neither device can load any clientside blazor websites.. I have tested:
|
I experienced a similar problem on IOS that I narrowed down to the CascadingAuthenticationState behaviour. Basically I created a new blazorwasm project, added a very basic custom AuthenticationStateProvider that returns an unauthenticated user and cunfigured 3 different routes:
The site works fine if the initial page loaded is the home page and I can navigate to the other two pages and see my unauthenticated state. If I try to hit refresh from a page different from the home page safari hangs showing the "Loading..." message: this confirms that the problem looks related to async operations during the app initialization as noted in #15989 You can find the test project here: https://github.com/ghidello/blazor.auth.problem.on.ios |
/cc @vargaz |
Adding more details. None of my projects use Auth. I was told that maybe the issue could be related to having a http call in an OnInitalizedAsync that gets called first on load of the app. And indeed all my apps that dont work right now do that, so I move one app to have a blank page in the first page with a link to the "real" app as a test - this did not help. Lastly so you have something to compare to, this site still works on iOS: https://blazorstrap.io (My original site that I said works also stopped working) |
For completeness (and the fact that iOS 13 is probably less than a month away and will support and be pushed by Apple to everything back to a 6s) https://blazorstrap.io does not work with any of the current iOS 13 builds... (no client side blazor site seems to work with iOS 13) |
IOS 13 is definitely a problem, but I think it would be good to understand why some sites load under 12.4 and some don’t |
+1 seeing this issue.
…________________________________
From: Chanan Braunstein <notifications@github.com>
Sent: Tuesday, August 20, 2019 1:51:45 PM
To: mono/mono <mono@noreply.github.com>
Cc: Ivan Josipovic <ivanjosipovic@outlook.com>; Manual <manual@noreply.github.com>
Subject: Re: [mono/mono] [wasm] Blazor: CSB randomly does not work on iOS (#16144)
IOS 13 is definitely a problem, but I think it would be good to understand why some sites load under 12.4 and some don’t
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#16144?email_source=notifications&email_token=ACIUWQ2LZ74KWKPX66VGXK3QFRKODA5CNFSM4IKU6GOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XTZQI#issuecomment-523189441>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACIUWQ5HJSZNGX4IIFY4P4TQFRKODANCNFSM4IKU6GOA>.
|
chanan https://blazorstrap.io still works on ios? |
Yes. Just loaded it both in safari and chrome. Version 12.4 |
Yes it loads now. Weird I tried multiple times about an hour and half ago and it was not loading. |
First load takes a bit till the dotnet dlls are cached. Haven’t touched the site today :) |
I have opened a bug report here: https://bugs.webkit.org/show_bug.cgi?id=201026 Hopefully they can provide a little assistance. I will open another about the IOS 13 beta |
I have filed a specific iOS Beta 13 issue here: https://bugs.webkit.org/show_bug.cgi?id=201028 If the information is not correct could someone let me know so the issue can be updated. |
The specific error is: As well as the issue: #16364 |
@kjpou1 Did you find out anything more about what specifically triggers the error in our case? People have been saying that some of their apps work and some don't, so do we know what's different between these two cases? If we knew, maybe we could identify some workaround. Do other WebAssembly apps work on iOS 13, or is there some known way to reproduce the problem without involving Mono WebAssembly? |
@SteveSandersonMS Nothing more than what is in the issue with and mentioned above. The issues were just opened with nobody assigned yet. The error above is the only thing that is printed in console when running the app. If trying to debug the issue then the application does not have that error and loads. I asked in the issue if there was any parameters that we could control to make the stack larger from our end. |
I have the same problem also: |
As iOS only allow the usage of iOS Webkit, it's so more related to the fact that this is the Webkit engine, than the fact that this is Chrome. |
@kjpou1 This webkit issue is not exactly the same you opened, but i'm pretty convinced it is somehow throwing for the same reasons. |
/cc @kg |
Currently with preview 9 all my sites work on iOS - but please keep in mind, while it might be fixed, there is also a chance it isn't, like I said in the initial report - it is (seemingly) random if a particular build works or not. |
This should be fixed by updating to AspNetCore Preview 9. Will close this for now and if need be open another issue against Preivew 9. |
There seem to be multiple issues at play here:
(Of those, I haven't observed 1. myself.) Unfortunately, iOS 13 / Safari 13, which will ship this Thursday, adds a few. BlazorStrap.io, for instance, now works for me on Safari/macOS, but still doesn't on Safari/iOS. It would previously fail with 3. (on both platforms, I believe), and now fails with 2., but only on iOS. My guess is the call stack limits are different between macOS and iOS, or perhaps between x86 and ARM. Even on macOS, though, I can't seem to get non-trivial Blazor pages to render without eventually running into 3.. |
This is not a good moment for me as i have to release something in production in maybe one or two days...Do you know if adding any delay at startup fix the problem on iOS 13 or is it totally messed up by Apple ? |
FWIW: regardless of Safari, client-side (WASM-based) Blazor is not production-ready (nor has Microsoft claimed otherwise). Only the Web Sockets-based server-side Blazor is ready as part of ASP.NET Core 3.0. That said, it's very unfortunate that Blazor worked fine (for me) with 12.x, but breaks in multiple ways in 13.0.
I've found that inserting |
Yes i know about this Production ready thing. But IMHO, theses bugs are more related to Apple not able to manage WebAssembly correctly or having not enough memory to manage things, than pure Microsoft bug. Of course, there is maybe some issues in mono-wasm that may variate this experience. But from my tests with my BlazorMobile plugin, iOS is the only platform to always have problems. Strangly, i never encountered any WebAssembly / Browser exception at runtime with Blazor with Edge (from UWP) and from GeckoView (from my Android app). I will test for the Task.Delay again so. Thanks for your feedback @chucker |
Yes, there are definitely WebKit-specific bugs here. (Mono-WASM's behavior may trigger/exacerbate them.) |
Well actually iOS 13 Safari version is very buggy with WASM or at least call stack size. I just tested with my iPad and even the samples doesn't work because of 2. - Unhandled Promise Rejection: RangeError: Maximum call stack size exceeded. . Also 3. but this is worarounded by the hint you received on another github post with "var Module;". The only workaround i found at the moment with the current Safari / iOS 13 version is by modifying the blazor.webassembly.js file and add give some time at startup on some delegates. It work on my iPad, but i cannot test on iPhone, i only have an iPhone 6 and of course Apple dropped iPhone 6 support for iOS 13. blazor.webassembly.ios13.fix.zip As i have no alternative, i will put it as an "Opt-in" in my plugin (mainly for iOS), but i wish Webkit will work better in the future. Actually tested my "big" Business app with my patch, and it seem to work. |
There has been a PR submitted to rectify the |
Just FYI, I tried it on an iPhone 8 with iOS 13.1, and it does work with your workaround. |
@chucker Thanks ! Also just FYI, i tested also iPhone 6s (bought one just for the tests), and actually, you need to set the timeout to 2 seconds instead of 1 in order to be sure to not fail on this older device. This add a total delay of 4 seconds (the fixed delegate is called twice before Blazor boot), but you will be sure it works on iPhone 6s. Not tested on iPhone SE otherwise. As @kjpou1 reforwarded my issue, you can see additional informations here |
Hi @Daddoon , |
@duyvt88 are you seeing any errors in the browser console (you'd need to remotely attach your iPad to a Mac)? Is your site publicly available so we can test it? |
@duyvt88 Please note that two PR are pending from Microsoft about fixing the issue on iOS 13. See dotnet/aspnetcore#14605 and dotnet/aspnetcore#14576 From this issue: #16986 (comment) |
@duyvt88 Also did you add the var Module; hack bit ? It's not included in my fix. |
@Daddoon I forgot to add it. I just added it here. Is it correct? |
@chucker Thank you. Let me prepare a sample site for you. |
@duyvt88 Yes should be enough ! If your blazor.webassembly.js file is then modified with the fix, you are good to go. |
From @chanan on Friday, August 9, 2019 2:55:29 AM
Preivew7. Tried on Safari, Edge ios, and Chrome.
I have several CSB sites hosted on github pages (some with DNS some without). When I push changes sometimes one works and sometimes it doesn't.
For example right now:
I fired up xcode to see if I can figure out why, however in both of them do not work in xcode and give the error:
My xcode is update: Version 10.3 (10G8)
Copied from original issue: dotnet/aspnetcore#12992
The text was updated successfully, but these errors were encountered: