maui
maui copied to clipboard
MAUI Blazor Hybrid different rendering on different platforms
Description
I have a very simple component which, to my surprise, is rendered differently on different platforms despite being hosted inside a BlazorWebView.
On Windows, its rendered as expected. On Android, however, the text is not centered. How is this possible? I do not believe I have any platform-specific code.
And is it possible to resolve this issue, and get consistent output on both/all platforms?
The component:
<div Style="height:250px;background-color:coral;align-content: center;">
<p style="text-align: center;">No items</p>
</div>
I have also re-created the component in MudBlazor here (same result): https://try.mudblazor.com/snippet/cumIbaGmMclCKdsj
I have created an example project that reproduces the issue here: https://github.com/mgj/MauiHybridRenderingIssue
Windows rendering:
Android rendering:
Steps to Reproduce
- In visual studio 2022 create a new ".NET MAUI Blazor Hybrid App"
- Add the following component (e.g. by replacing the contents of Home.razor):
<div Style="height:250px;background-color:coral;align-content: center;">
<p style="text-align: center;">No items</p>
</div>
- Deploy the app on Windows - Observe it is rendered as expected
- Deploy the app on Android - Observe it is NOT rendered as expected
Link to public reproduction project repository
https://github.com/mgj/MauiHybridRenderingIssue
Version with bug
8.0.92 SR9.2
Is this a regression from previous behavior?
No, this is something new
Last version that worked well
No response
Affected platforms
Android
Affected platform versions
Android 14
Did you find any workaround?
I did not find a workaround
Relevant log output
No response
We've found some similar issues:
- #13851 , similarity score: 83%
If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.
Note: You can give me feedback by 👍 or 👎 this comment.
We've found some similar issues:
- Blazor MAUI - Same UI code not render on Windows but renders on Android #13851 , similarity score: 83%
If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.
Note: You can give me feedback by 👍 or 👎 this comment.
It is similar, but opposite. In that issue the code works on Android, but not on Windows. In my issue its the opposite. I believe my issue is simpler and easier to reproduce than #13851.
In mobile development, you need to use relative positioning like EM or VH etc. Pixels render differently on different platforms. So its not really a bug its just to do with how mobile platforms render the html. Also if you use "display:flex" it will work on all platforms for your specific issue.
This issue has been verified using Visual Studio 17.12.0 Preview 3( 8.0.92 &8.0.82 & 8.0.3). Can repro this issue on android platform.
So as mentioned in another comment it seems possible to work around it by using this instead:
<div Style="display:flex;height:250px;background-color:coral;">
<p style="flex-grow: 1;text-align: center;align-self: center;">No items</p>
</div>
I still believe this is an issue worth looking into. Ideally it would be impossible for the rendering to ever be different on different platforms, as having to double- and tripple-check all UI on all platform slows down productivity and takes away from the benefits of using a cross-platform solution like MAUI (Blazor Hybrid).
Thank you for the feedback and the confirmation on reproducibility.
Using pixels for positioning in HTML on mobile platforms, especially in a MAUI Blazor WebView, is a bad idea because pixels are absolute units and don’t scale across different screen sizes and resolutions. With mobile devices, especially on iPhone and Android, you’re dealing with a massive range of screen densities (DPI) and aspect ratios.
On iPhones, the ecosystem is a bit more controlled with higher pixel densities (Retina displays), so you might get some consistency. But even then, you've got variations in screen sizes—from something like the iPhone SE to the 15 Pro Max—so pixel-based layouts can still lead to misalignment or scaling issues.
On Android, it's even worse because of the sheer number of devices out there. Screens range from low to high DPI, and aspect ratios vary a lot more. Pixels on one device might result in a UI that’s too small or completely breaks the layout on another.
Relative positioning, using percentages, vw, vh, or flexbox/grid, is just better because it scales with the device’s viewport. It means your layout adapts to whatever screen size or resolution the user has, whether it’s an iPhone or Android, and you end up with a much more consistent user experience. Pixels are rigid, and in mobile development, that rigidity breaks things—relative units give you the flexibility you need.
In short its not a bug in the WebView its a symptom of mobile screens. Try it with a simple html web page, it will render differently on Android phones and iPhone. Pixel based positioning is your enemy. Don't use it. 👍
Using pixels for positioning in HTML on mobile platforms, especially in a MAUI Blazor WebView, is a bad idea because pixels are absolute units and don’t scale across different screen sizes and resolutions. With mobile devices, especially on iPhone and Android, you’re dealing with a massive range of screen densities (DPI) and aspect ratios.
On iPhones, the ecosystem is a bit more controlled with higher pixel densities (Retina displays), so you might get some consistency. But even then, you've got variations in screen sizes—from something like the iPhone SE to the 15 Pro Max—so pixel-based layouts can still lead to misalignment or scaling issues.
On Android, it's even worse because of the sheer number of devices out there. Screens range from low to high DPI, and aspect ratios vary a lot more. Pixels on one device might result in a UI that’s too small or completely breaks the layout on another.
Relative positioning, using percentages, vw, vh, or flexbox/grid, is just better because it scales with the device’s viewport. It means your layout adapts to whatever screen size or resolution the user has, whether it’s an iPhone or Android, and you end up with a much more consistent user experience. Pixels are rigid, and in mobile development, that rigidity breaks things—relative units give you the flexibility you need.
In short its not a bug in the WebView its a symptom of mobile screens. Try it with a simple html web page, it will render differently on Android phones and iPhone. Pixel based positioning is your enemy. Don't use it. 👍
I think you're missing the point of this issue. I'm not using pixels to position the text. Its just the height of the container. It doesn't matter if the height is different on different screens. This issue is not related to screen size. You can reproduce the issue using identical screens for both platforms. You can reproduce it without defining the height in pixels.
When a cross platform UI toolkit, that does not map UI elements to their native counterparts, renders the cross platform content differently on different platforms, its a bug.
I'm not sure you understand how the BlazorWebView works. Let me explain.
In a .NET MAUI application, the BlazorWebView control embeds Blazor components into native mobile applications. When using BlazorWebView, the Blazor components are rendered using the platform's native web rendering engine. This means:
iOS (Safari WebKit Engine): On iOS devices, BlazorWebView utilizes the WebKit engine, which is the underlying engine for Safari. WebKit is the native web rendering engine provided by Apple, ensuring that Blazor components are rendered in the same way as they would be in a Safari browser on iOS.
Android (Chromium-based WebView): On Android devices, BlazorWebView uses the Chromium-based WebView. This WebView is essentially a stripped-down version of the Chrome browser that is embedded into Android applications. It provides the same rendering capabilities as the Chrome browser, ensuring consistency between web content in native apps and the Chrome browser itself.
In summary, BlazorWebView delegates rendering to the device's native web rendering engine (WebKit for iOS and Chromium for Android), allowing Blazor components to run seamlessly within a mobile app without needing a separate browser.
So the behaviour you're seeing has nothing to do with MAUI, its to do with the differences between WebKit and WebView.
So we agree: It has nothing to do with screen size or using "px". Good.
So we agree: It has nothing to do with screen size or using "px". Good.
The HTML was wrong, as you figured out by using flexbox. But the issue has nothing to do with MAUI; it's down to the quirks of different rendering engines. This isn't a bug and doesn’t require action on that front. You've shown that rendering engines vary, and I wanted to point out that using "px" for layout-based CSS, where elements need to be positioned relative to each other, isn't the best practice. It’ll cause more headaches later. Stick with fluid units, or you'll be chasing your tail, especially when you get to WebKit and see fonts looking different and layouts shifting. It’s just part of the challenge in multi-platform development.
I guess its easy to determine if this is us (.NET MAUI) or just the platform browser engine (and thus you probably need to tweak your HTML/CSS).
On the devices where you observe this behavior, if you open the web application in the device browser instead of inside of your .NET MAUI app with the BlazorWebView, does it then still renderer wrong?
If yes, tweak your HTML/CSS and welcome to the world of web standards. If not, then it is specific to our BlazorWebView and we should look into fixing it.
Could you let us know? Thanks!
I guess its easy to determine if this is us (.NET MAUI) or just the platform browser engine (and thus you probably need to tweak your HTML/CSS).
On the devices where you observe this behavior, if you open the web application in the device browser instead of inside of your .NET MAUI app with the BlazorWebView, does it then still renderer wrong?
If yes, tweak your HTML/CSS and welcome to the world of web standards. If not, then it is specific to our BlazorWebView and we should look into fixing it.
Could you let us know? Thanks!
Chrome renders it as the WebView, Firefox renders it as Windows. Since BlazorWebView uses the WebChromeClient I guess this is expected. I did not test with the AOSP browser but I think it is now based on Chromium(?) so it'll probably yield the same result as Chrome.
Thank you for looking into this, feel free to close the issue. I'll go complain about the world of web standards instead :P
Sorry it wasn't the answer you're looking for, but glad we were able to determine its not .NET MAUI 😄 good luck!