* Move HybridWebView platform code to handlers
And run everything through the mappers.
Fixes#24269
* WIP
* Fix API files
* API
* API
* API
* Change platform checks
Fixes: https://github.com/dotnet/maui/issues/24740
Using this in a project:
<PackageReference Include="akgul.Maui.DataGrid" Version="4.0.4" />
Then, in a XAML file:
xmlns:dg="clr-namespace:Maui.DataGrid;assembly=Maui.DataGrid"
...
<dg:DataGrid />
Would crash with:
[0:] [13:46:57 FTL] Inner Exception:
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Maui.Controls.Xaml.BindingExtension.<Microsoft.Maui.Controls.Xaml.IMarkupExtension<Microsoft.Maui.Controls.BindingBase>.ProvideValue>g__CreateBinding|40_0(<>c__DisplayClass40_0& ) in /_/src/Controls/src/Xaml/MarkupExtensions/BindingExtension.cs:line 46
at Microsoft.Maui.Controls.Xaml.BindingExtension.Microsoft.Maui.Controls.Xaml.IMarkupExtension<Microsoft.Maui.Controls.BindingBase>.ProvideValue(IServiceProvider serviceProvider) in /_/src/Controls/src/Xaml/MarkupExtensions/BindingExtension.cs:line 27
at Maui.DataGrid.DataGrid.InitializeComponent() in D:\Maui.DataGrid\Maui.DataGrid\Microsoft.Maui.Controls.SourceGen\Microsoft.Maui.Controls.SourceGen.CodeBehindGenerator\DataGrid.xaml.sg.cs:line 53
at Maui.DataGrid.DataGrid..ctor() in D:\Maui.DataGrid\Maui.DataGrid\DataGrid.xaml.cs:line 46
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Constructor(Object obj, IntPtr* args)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
Inspecting the IL, I see:
BindingBase val115 = ((IMarkupExtension<BindingBase>)(object)val31).ProvideValue((IServiceProvider)null);
So, it is indeed passed a `null` `IServiceProvider`.
Introduce a unit test and check for `null` as a fix.
Context: https://github.com/dotnet/maui/pull/23769
Context: https://github.com/dotnet/android/pull/9300026e046b introduced `HybridWebView`, which unfortunately introduces
trimmer warnings in the `dotnet new maui` project template:
> dotnet new maui
> dotnet build -f net9.0-android -c Release -p:TrimMode=Full
...
hellomaui succeeded with 1 warning(s) (7.9s)
/_/src/Core/src/Handlers/HybridWebView/HybridWebViewHandler.Android.cs(53,5):
Trim analysis warning IL2026: Microsoft.Maui.Handlers.HybridWebViewHandler.HybridWebViewJavaScriptInterface.SendMessage(String):
Using member 'Java.Interop.ExportAttribute.ExportAttribute(String)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code.
[ExportAttribute] uses dynamic features.
This is due to usage of `Java.Interop.ExportAttribute`:
private sealed class HybridWebViewJavaScriptInterface : Java.Lang.Object
{
//...
[JavascriptInterface]
[Export("sendMessage")]
public void SendMessage(string message)
`Java.Interop.ExportAttribute` makes heavy usage of unbounded
System.Reflection, System.Reflection.Emit, etc. for it to be able to
work. It brings in an additional assembly `Mono.Android.Export.dll` as
well.
It is inherently trimming unsafe, but how did it get through these
tests?
08ff124638/src/TestUtils/src/Microsoft.Maui.IntegrationTests/AndroidTemplateTests.cs (L50-L61)
This slipped through, unfortunately, as we had missed solving all the
trimmer warnings in `Mono.Android.Export.dll`! dotnet/android#9300
aims to fix that.
After dotnet/android#9300, new trimming warnings specific to .NET MAUI
will surface such as the one above.
But we can easily replace `[Export]` by:
* Define a Java interface & create a binding for it in C#, we already
have `maui.aar` setup for this.
* We can simply implement the interface in C# and remove `[Export]`.
Lastly, I fixed some of the defaults in `Metadata.xml`, it didn't look
like we were automatically making Java interfaces `internal`. It looks
like we probably made `ImageLoaderCallback` public by mistake.
Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit
From Version 10.0.0-prerelease.24459.1 -> To Version 10.0.0-prerelease.24466.1
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Microsoft.iOS.Sdk.net9.0_17.5 , Microsoft.MacCatalyst.Sdk.net9.0_17.5 , Microsoft.macOS.Sdk.net9.0_14.5 , Microsoft.tvOS.Sdk.net9.0_17.5
From Version 17.5.9317-net9-rc2 -> To Version 17.5.9334-net9-rc2
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Fixed - 22452 - ios Shell
* Added Test case
* Modified test case file
* Modified test case
* Added images for test case
* Modified test case file
* Modified test cases
* Modified test case
* Modified test case
* Added image for test case
* Committed the changes of the issue
* properly fixed the Object disposed exception
* Added the proper name of test case
* Removing the unneccesary space
* fix-15196-Removed the Dispose method.
* fix-15196-Modified and removed the changes in test case and sample.
---------
Co-authored-by: AhamedAliNishad <ahamedalinishad.j@syncfusion.com>
Context: 7efca8efb3
Context: https://github.com/xamarin/Xamarin.Forms/pull/7407
For Debug builds, .NET MAUI runs XamlC in a "ValidateOnly" mode, which
avoids writing `.dll` files at the end. This way, we get faster
builds, but still emit the same errors and warnings that would be
emitted in `Release` mode.
Right now, the `ValidateOnly` flag is only checked at the end of the
process to skip writing files. I looked for some places taking time,
such as:
36.30ms (1.1%) microsoft.maui.controls.build.tasks!Microsoft.Maui.Controls.Build.Tasks.NodeILExtensions+<PushServiceProvider>d__12.MoveNext()
20.20ms (0.6%) microsoft.maui.controls.build.tasks!Microsoft.Maui.Controls.Build.Tasks.NodeILExtensions+<PushParentObjectsArray>d__9.MoveNext()
1.21ms (0.0%) microsoft.maui.controls.build.tasks!Microsoft.Maui.Controls.Build.Tasks.NodeILExtensions.PushXmlLineInfo(class Microsoft.Maui.Controls.Xaml.INode,class Microsoft.Maui.Controls.Build.Tasks.ILContext)
And added checks to just return early in these methods.
With this change in-place, an incremental build of a `dotnet new maui`
project template:
Before:
1704 ms XamlCTask 4 calls
After:
1402 ms XamlCTask 4 calls
This probably saves a little less than 100ms per call, but in this
example it is running once per platform. This improvement probably
will help even more for larger projects with many XAML files.
The dev tools settings were being set on a separate webview that wasn't being used. This change applies the settings to the webview actually being used.
Fixes#24497
* Split off DatePicker.HandlerDoesNotLeak into its own UI test.
* Changed RunMemoryTest to take in INavigation instead of NavigationPage, renamed Issue24147 to MemoryTests and changed it to take in Text from Entry to determine which Handler to use, Removed Issue22072 as that's now in MemoryTests
* Renamed Issue24147 in Tests.Shared to MemoryTests, added methods to check DatePicker and WebView. Added automationids in HostApp MemoryTests
### Description of Change
Fixes an issue where scrolling of SwipeView's parent is disabled during
swipe but not reenabled when the swipe is cancelled by manually moving
the touch below the threshold.
### Issues Fixed
Fixes#23441Fixes#16856
Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit
From Version 9.0.0-prerelease.24420.3 -> To Version 10.0.0-prerelease.24459.1
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Rui Marinho
Šimon Rozsíval
Eilon Lipton
Jonathan Peppers
Shane Neuville
dotnet-maestro[bot]
Matthew Leibowitz
Stephane Delcroix
NirmalKumarYuvaraj
Tamilarasan Paranthaman
BagavathiPerumal
SuthiYuvaraj
dustin-wojciechowski
Jonathan Dick
Eric
Oleksandr Dobrynin
Alberto Aldegheri
Jakub Florkowski