-
Notifications
You must be signed in to change notification settings - Fork 1.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
[net8.0] Merge main again #15367
Merged
Merged
[net8.0] Merge main again #15367
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* fix(bug): Fix `RemainingItemsThresholdReached` on Windows * Fixed an issue where the `CollectionView.RemainingItemsThresholdReached` event wasn't firing on Windows. * Added a DeviceTest for the event * Remove switch statement * Update src/Controls/src/Core/Handlers/Items/ItemsViewHandler.Windows.cs Co-authored-by: Rui Marinho <me@ruimarinho.net> --------- Co-authored-by: Mike Corsaro <mikecorsaro@microsoft.com> Co-authored-by: Rui Marinho <me@ruimarinho.net>
* initial fix * Add tests * round test asserts for android * add conditional for no wrap and add more tests * Adjust tests for android * do not run on windows for now * Add changes to work on Windows * limit the labels text to the parent container width and adjust tests * Auto-format source code * also add a height restriction * Auto-format source code --------- Co-authored-by: tj-devel709 <tjlambert@microsoft.com> Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
Context: #12130 Context: https://github.com/angelru/CvSlowJittering Profiling a .NET MAUI customer sample while scrolling on a Pixel 5, I see some interesting time being spent in: (0.76%) microsoft.maui!Microsoft.Maui.Graphics.MauiDrawable.OnDraw(Android.Graphics.Drawables.Shapes.Shape,Android.Graphics.Canv (0.54%) microsoft.maui!Microsoft.Maui.Graphics.MauiDrawable.SetDefaultBackgroundColor() This sample has a `<Border/>` inside a `<CollectionView/>` and so you can see this work happening while scrolling. Specifically, I found a couple places we had code like: _borderPaint.StrokeWidth = _strokeThickness; _borderPaint.StrokeJoin = _strokeLineJoin; _borderPaint.StrokeCap = _strokeLineCap; _borderPaint.StrokeMiter = _strokeMiterLimit * 2; if (_borderPathEffect != null) _borderPaint.SetPathEffect(_borderPathEffect); This calls from C# to Java 5 times. Creating a new method in `PlatformInterop.java` allowed me to reduce it to 1. I also found: void SetDefaultBackgroundColor() { using (var background = new TypedValue()) { if (_context == null || _context.Theme == null || _context.Resources == null) return; if (_context.Theme.ResolveAttribute(global::Android.Resource.Attribute.WindowBackground, background, true)) { var resource = _context.Resources.GetResourceTypeName(background.ResourceId); var type = resource?.ToLowerInvariant(); if (type == "color") { var color = new AColor(ContextCompat.GetColor(_context, background.ResourceId)); _backgroundColor = color; } } } } This is doing a lot of unnecessary stuff: looking up a resource by name, etc. I found a very simple Java example we could put in `PlatformInterop.java`: https://stackoverflow.com/a/14468034 After these changes, I now see: (0.28%) microsoft.maui!Microsoft.Maui.Graphics.MauiDrawable.OnDraw(Android.Graphics.Drawables.Shapes.Shape,Android.Graphics.Canv (0.04%) microsoft.maui!Microsoft.Maui.Graphics.MauiDrawable.SetDefaultBackgroundColor() This improves the performance of any `<Border/>` (and other shapes) on Android, and drops about ~1% of the CPU time while scrolling in this example.
* Fix Android CollectionView EmptyView * Update src/Controls/src/Core/Handlers/Items/ItemsViewHandler.Android.cs Co-authored-by: E.Z. Hart <hartez@users.noreply.github.com> * Fixed build errors * Auto-format source code --------- Co-authored-by: E.Z. Hart <hartez@users.noreply.github.com> Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
Context: #12130 Context: https://github.com/angelru/CvSlowJittering Context: https://github.com/jonathanpeppers/lols Testing a customer sample and my LOLs per second sample, I could see a lot of time (5.1%) spent in `PrepareForTextViewArrange()`: 1.01s (5.1%) microsoft.maui!Microsoft.Maui.ViewHandlerExtensions.PrepareForTextViewArrange(Microsoft.Maui.IViewHandler,Microsoft.Maui 635.99ms (3.2%) mono.android!Android.Views.View.get_Context() Most of the time is spent just calling `View.Context` to be able to do: internal static int MakeMeasureSpecExact(this Context context, double size) { // Convert to a native size to create the spec for measuring var deviceSize = (int)context!.ToPixels(size); return MeasureSpecMode.Exactly.MakeMeasureSpec(deviceSize); } In eea91d3, I added an overload for `ToPixels()` that allows you to get the same value with an `Android.Views.View` -- avoiding the need to call `View.Context`. So we can instead do: internal static int MakeMeasureSpecExact(this PlatformView view, double size) { // Convert to a native size to create the spec for measuring var deviceSize = (int)view.ToPixels(size); return MeasureSpecMode.Exactly.MakeMeasureSpec(deviceSize); } After these changes, it seems to be ~2.7% better: 420.68ms (2.4%) microsoft.maui!Microsoft.Maui.ViewHandlerExtensions.PrepareForTextViewArrange(Microsoft.Maui.IViewHandler,Microsoft.Maui The `View.Context` call is now completely gone.
* Fix Flyout page on iPad * Update FlyoutPageTests.cs * - use better override for rotation * - fix bounds for phone * - modify ipad flyoutpage to open over content * - fix click off frame * - fix a few issues with flyoutpage layout on ipad * -fix RTL * - fix pan offset calculations * - fix width check * - add bool to allow users to toggle behavior * Auto-format source code --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
* Remove view from previous containerview * - fix shell test to correctly add nav bar * - fix wiring up to modal pages * - fix extraction of currentpage
* Removed Controls Navigation Controller This class currently isn't used anywhere so its existence is confusing * - use mapper methods for platform specifics * - fix handler registration * Update ShellTests.cs
…14905) * Changes updating Android ImageButton Padding * Updated tests * Auto-format source code --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
* [CI] Do not rebuild the ms tasks on device tests. We do not want to rebuild the tasks but use the workloads to run the device tests. The reasons for this tests are: 1. We should be testing what we ship, not a diff build. 2. We cna emsure that the megapipeline will be testing with the bumped android and iOS sdks. * Allow to rebuild the tasks which is what is expected in the maui repo. * Use the correct template.
) Bumps [Microsoft.WindowsAppSDK](https://github.com/microsoft/windowsappsdk) from 1.3.230331000 to 1.3.230502000. - [Release notes](https://github.com/microsoft/windowsappsdk/releases) - [Commits](https://github.com/microsoft/windowsappsdk/commits) --- updated-dependencies: - dependency-name: Microsoft.WindowsAppSDK dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Ensure MaximumWidth is used when arranging If Width is not explicitly set but MaximumWidth is, we should still use that as part of the arranging calculations * Account for alignment * Add tests * Auto-format source code --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
* Set Icon to null and back again, working around Android issue There seems to be an Android bug where it sometimes doesn't compute the updated icon position correctly, treating IconGravityTextEnd as if it were IconGravityTextStart. Setting the Icon to null and then back again forces the resetIconDrawable call here https://github.com/material-components/material-components-android/blob/25b3c2b15c9b9499993d6d4a5fb491ffce04517a/lib/java/com/google/android/material/button/MaterialButton.java#L852-L869 to happen which seems to make things work properly. Fixes #11755 * Add device test * Update test so results show in window * Update to use AttachAndRun, for performance * Use new base class method to call AttachAndRun * Remove unneeded InvokeOnMainThreadAsync * Update to use CreateHandlerAndAddToWindow * Use Theory to test all 4 icon positions * Update the logic for Top as well
…12011) * [Android] Use different view types per item template Previously we were returning a single view type id for all 'items' in collectionview, which meant if you were using a template selector, and had a variety of returned different DataTemplates, each would share the same recycled item. When a recycled item is reused for a different template, it causes the view for that template to be recreated to be correct for the template selected. This change returns a unique item id per DataTemplate.Type, so that recycled items should always have the correct DataTemplate.Type and not need to be recreated with a different view hierarchy. * [iOS] Distinct Cell reuse id's for different DataTemplates Like on Android, we were using a single cell reuse identifier for iOS "items" regardless of if they had different DataTemplates. If you were using a data template selector, and returned different data templates, whenever a recycled cell's data template didn't match the data template it needed to display for the new/recycled context, the whole view tree of that template would be recreated. This change ensures we have a unique cell reuse id for every different DataTemplate.Type that might be returned by the template selector so that when a cell is recycled it should always be reused for the same Data Template it was created for, and so the view hierarchy won't be recreated. This does require the DetermineCellReuseId to know the indexpath we're getting it for, so a new method was introduced, internal for NET7, protected for NET8+, and in NET8+ the old method is obsoleted. * Switch up some xaml controls in the sample * Expose Id internally to use for android view types * Cache datatemplates for unique item view types * Api changes (overrides) * Improve sample * Remove api txt change that shouldn't have been added * Update src/Controls/src/Core/Handlers/Items/Android/Adapters/ItemsViewAdapter.cs Co-authored-by: E.Z. Hart <hartez@users.noreply.github.com> * Update src/Controls/src/Core/Handlers/Items/Android/Adapters/ItemsViewAdapter.cs Co-authored-by: Rui Marinho <me@ruimarinho.net> * Update src/Controls/src/Core/Handlers/Items/Android/Adapters/ItemsViewAdapter.cs Co-authored-by: Rui Marinho <me@ruimarinho.net> * Use DataTemplate Id for cellReuseId * Calculate correct position for carousel adapter The `CarouselViewAdapter` loops by basically returning a very large value for item count of its adapter/source which means the recyclerview is going to ask for view types with a position value that does not actually exist. Previously this was ok because we returned only a single item view type ever, however now that we want to return a different type for template selector scenarios where there are potentially multiple template types, we need to override also the `GetItemViewType` and pass in the calculated position in the list properly (as we do in `OnBindViewHolder` here already) since the base `ItemsViewAdapter` class now calls `ItemsSource.GetItem(position)` in its `GetItemViewType()` call. --------- Co-authored-by: Rui Marinho <me@ruimarinho.net> Co-authored-by: E.Z. Hart <hartez@users.noreply.github.com> Co-authored-by: Shane Neuville <shneuvil@microsoft.com>
Bumps Microsoft.Web.WebView2 from 1.0.1722.45 to 1.0.1774.30. --- updated-dependencies: - dependency-name: Microsoft.Web.WebView2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Remove Compat components from legacy gallery * - cleanup android gallery * - remove diagnose capability * - fix up WinUI to run * - last few missing files on winui * - fix iOS to compile * Auto-format source code * - fix compile errors * - fixup test agent search * Auto-format source code --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
…an sufficient to display full size (#14902) * Add tests for overlapping stuff, checkpoint before working out the multiple arrange stuff * Working, just needs a lot of cleanup * More cleanup * Break down decompress method * Add test for multiple Arrange calls * More comprehensive test for multiple Arrange calls * No longer need the Available* methods * Pare down star decompression * Fix empty star row/column error * Make the grid structure methods clearer in their purpose * Remove return from ResolveStars * Auto-format source code * Account for greedy control measurement behavior * Auto-format source code * Remove extraneous using * Prevent unnecessary LayoutSubviews in xplat backing controls --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
* More stuff with query * Update to Appium 2.0 * Cleanup * Fix tests * Add mac tests * Multiple testcase * Fixes for windows * Deploy as unpackaged app * Fixes for run UITests on windows * Cleanup and move to TestUtils projects for Appium and Xamarin.UITest * Fix references * Add to mac sln * Fix sln * Add uitest yaml * Fix sln * Update yml * more fixes * again powershell * fix ident * Add path and try call cake * Fix * Start background * Start appium on the background * Just run android for now * try install app * try again * if it fails continue * fix paths * appium * try again * try again * fix * again * try again * location of samples * build samples * do not skip xcode * more debug info * Publish test results * nUnit tests for now * try any file * no retry * try vstest * FIX PATH * install more drivers * usenuget when building samples * Move to helpers * Try run iOS tests * try build both * Add ALLTests * Android folder * fixes * try again * Fix path * Cleanup android cake * cleanup iOS cake * add mac cake * fix version * try again * try again * upDATE TOOLS * try again * fix again * again * again * again * rollback xharness * increase timeout * run with dotnet path * Fix dir * Try again * fix * Fix * build and then run tests * fix platformVersion passed to APPIUM * Don t do verbosity * Log for appium * Try 16.2 * Add platform to appium logs * Fix * Start test server * Wait for server to start * Fix typo * Add windows cake * Set uitests windows yaml * provision on macos only * Fix path for app windows * Rename winui * Try again * Make sure to stop and dispose the server * fix template * Install windows driver too * Better appium install drivers * specify device * Fix binlog android * Run device tests in release * Try no path * Try with debug configuration * try build samples just for that platform * Release * rename to match platform * try cleanup * Add mac uitests * Build only for catalyst * Add information * Version mac * Fix folder path * Try build and run windows tests * more stuff on install script * Add retry for ios * run always on xamarin pool * Fix windows * Allow to pass configuration to catalyst * Add bindir info * Try fix windows build * Try set env variables before * [Sample] Clean fields when tapping login button * Take screenshot before querying text element * Enable automationmode-without-authentication * Try using action instead * Use same machine pool as ios/android for mac * Change entry to not get autocorrect pop-up and add delay before click * Disable keyboard completion for catalyst runs * Auto-format source code * Update sln * Fix csproj * Add Sample UITests * Fix yaml * Use the new app uitest sandbox project * Remove old code * Cleanup * Fix Android manifest * Fix build for tizen * Rename projects * Some more renames * Fix ios for PR's * Update MainPageTests.cs * Add to mac slnf * Try more stuff for the mac * Try run before * don t set automation mode * Try Xcode select and move to ventura * Fix script * Dont xcode select * Bool and not string * try old appium * Fix version * Can we skip provisioning * We can't skip provisioning * Dont provision on windows * Update sln and packages * Update node * Configure the windows path to the exe * Auto-format source code --------- Co-authored-by: Scott Banning <scoban@microsoft.com> Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
* Adjust index path for cell reuseid in carouselview Since CarouselView uses a fake number of items for looping effect like android does, we also need to correct the index used in the base items controller to be the actual item index, not the looped one. * Fix return * Remove ifdef for net8, we are net8 This was also masking the public api txt warnings, but have added the unshipped api's as well.
* Wait for root page to load before processing modal * Update ModalTests.iOS.cs
Context (Fixes?): xamarin/Essentials#1996 Context: https://android.googlesource.com/platform/frameworks/base/+/a12044215b1148826ea9a88d5d1102378b13922f/core/java/android/net/ConnectivityManager.java#2412 Context: https://github.com/xamarin/xamarin-android/blob/ff5455ca95fc83c788e957353114578abf3b4f54/Documentation/guides/internals/debug-jni-objrefs.md#crash-via-unhandled-exception In xamarin/Essentials#1996, the customer reports an app crash: AndroidRuntime: FATAL EXCEPTION: ConnectivityThread AndroidRuntime: Process: ***, PID: 31179 AndroidRuntime: android.runtime.JavaProxyThrowable: System.NotSupportedException: Unable to activate instance of type Xamarin.Essentials.Connectivity+EssentialsNetworkCallback from native handle 0x780d4cef34 (key_handle 0x522746d). ---> System.MissingMethodException: No constructor found for Xamarin.Essentials.Connectivity+EssentialsNetworkCallback::.ctor(System.IntPtr, Android.Runtime.JniHandleOwnership) ---> Java.Interop.JavaLocationException: Exception of type 'Java.Interop.JavaLocationException' was thrown. AndroidRuntime: --- End of inner exception stack trace --- AndroidRuntime: at Java.Interop.TypeManager.CreateProxy (System.Type type, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x000b5] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) [0x00111] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: --- End of inner exception stack trace --- AndroidRuntime: at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) [0x0017e] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at Java.Lang.Object.GetObject (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type type) [0x00023] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at Java.Lang.Object._GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00017] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at Java.Lang.Object.GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00000] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at Java.Lang.Object.GetObject[T] (System.IntPtr jnienv, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00006] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at Android.Net.ConnectivityManager+NetworkCallback.n_OnCapabilitiesChanged_Landroid_net_Network_Landroid_net_NetworkCapabilities_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_network, System.IntPtr native_networkCapabilities) [0x00000] in <e41c0215a1b34d5f990de0d09dbe0e84>:0 AndroidRuntime: at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.42(intptr,intptr,intptr,intptr) AndroidRuntime: at crc64a0e0a82d0db9a07d.Connectivity_EssentialsNetworkCallback.n_onCapabilitiesChanged(Native Method) AndroidRuntime: at crc64a0e0a82d0db9a07d.Connectivity_EssentialsNetworkCallback.onCapabilitiesChanged(Connectivity_EssentialsNetworkCallback.java:50) AndroidRuntime: at android.net.ConnectivityManager$NetworkCallback.onAvailable(ConnectivityManager.java:3580) AndroidRuntime: at android.net.ConnectivityManager$CallbackHandler.handleMessage(ConnectivityManager.java:3793) AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:107) AndroidRuntime: at android.os.Looper.loop(Looper.java:237) AndroidRuntime: at android.os.HandlerThread.run(HandlerThread.java:67) When there is an exception "chain" of `NotSupportedException` > `MissingMethodException` mentioning a "missing constructor" with a `(System.IntPtr, Android.Runtime.JniHandleOwnership)` signature, it means that Java is calling a method on a C# class: // Java ConnectivityManager.NetworkCallback javaCB = … javaCB.onCapabilitiesChanged(…); and .NET Android could not find an existing instance associated with the Java instance `javaCB`, and is attempting to create a new C# instance to subsequently invoke a method on it. Usually, Java has this instance because it was created in C#: var networkCallback = new EssentialsNetworkCallback(); manager.RegisterNetworkCallback(request, networkCallback); so where did the instance go? There are generally two ways that the mapping between a Java instance and C# instance are lost: 1. Horrible terrible no good very bad GC bug, or 2. Someone called `.Dispose()` when they shouldn't have. (1), while a possibility, is rarely the case. (2) is far more common. To track down such things, you [capture a GREF log][0], which allows you to see where e.g. `key_handle 0x522746d` (which comes from the exception message) was disposed: +g+ grefc 217 gwrefc 0 obj-handle 0x9/I -> new-handle 0x25f6/G from thread '(null)'(20) … handle 0x25f6; key_handle 0xf3ac36b: Java Type: `crc64a0e0a82d0db9a07d/Connectivity_EssentialsNetworkCallback`; MCW type: `Xamarin.Essentials.Connectivity+EssentialsNetworkCallback` … -g- grefc 216 gwrefc 0 handle 0x25f6/G from thread '(null)'(20) … If it's a GC bug, the `-g-` message is from thread `finalizer`. If it's a "premature `.Dispose()`" bug, the `-g-` message will *not* be from the finalizer thread, and the associated stack trace (if present) will include a `Dispose()` method invocation. In the absence of a complete GREF log, we have to use our imagination a bit: what would cause `.Dispose()` to be invoked, and then a subsequent `NotSupportedException`+`MissingMethodException`? ***Enter multithreading…*** Turns Out™ that `ConnectivityManager` appears to [make use of][1] multiple threads, which provides this possible chain of events: 1. Thread 1 (C#) calls `manager.RegisterNetworkCallback(request, networkCallback)` 2. Thread 2 (Java) obtains a Java-side reference to `networkCallback`, which we'll refer to as `javaCB`: `ConnectivityManager.NetworkCallback javaCB = …` 3. Thread 1 (C#) later calls `manager.UnregisterNetworkCallback(networkCallback)` 4. Thread 1 (C#) calls `networkCallback.Dispose()`, which severs the mapping between `javaCB` and `networkCallback`. 5. Thread 2 (Java) calls `javaCB.onCapabilitiesChanged()` 6. This hits the marshal method for `ConnectivityManager.NetworkCallback.OnCapabilitiesChanged()`, which needs to get an instance upon which to invoke `.OnCapabilitiesChanged()`. This promptly blows up with the `NotSupportedException`. The fix, in this case, is to *not* do step (4): avoiding the `.Dispose()` invocation allows `javaCB` to remain valid, and will prevent `javaCB.onCapabilitiesChanged(…)` from throwing. This *does* mean that the `networkCallback` instance will live longer, as we'll need to wait for a full cross-VM GC to occur before it is collected, but this is "safest" and prevents the crash. *In general*, if another Java-side thread can potentially invoke methods on a C# subclass, you *should not* call `.Dispose()` on instances of that type. [0]: https://github.com/xamarin/xamarin-android/blob/ff5455ca95fc83c788e957353114578abf3b4f54/Documentation/guides/internals/debug-jni-objrefs.md#collect-complete-jni-object-reference-logs [1]: https://android.googlesource.com/platform/frameworks/base/+/a12044215b1148826ea9a88d5d1102378b13922f/core/java/android/net/ConnectivityManager.java#2248
* Set Version for Windows * moved
* [CI] Remove the template explosion in the CI via a matrix Templates are being abused and is resulting in a tempalte explosion, this means that when the templates get expanded we have 100 thousans of lines generated. Azure devops has a limit in the size of the expanded template, and once that limit is reached, the pipeline wont be able to execute. This changes makes the problem go away since a matrix is a native object for azure pipelines and does not get expanded. This PR only takes care of the android emulator tests. A similar PR can be found in the xamarin-macios project: xamarin/xamarin-macios#18312 * Indentation. * Fix matrix case anming. * Fix name. * The job does not longer need to be unique per api. * Same with the display name.
* Fix issue with CollectionView ignoring margins for content * Auto-format source code --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com>
* Add UITest Gallery and some simple tests * Auto-format source code * Remove automation hints for mac accessibility and use mouse instead of touch pointer as its not supported * Get the navigation bar back button for mac/ios tests * Auto-format source code * Fix bad merge for ios settings and minor tweaks/ignore tests * Auto-format source code * Try install 14.2 on monterrey --------- Co-authored-by: GitHub Actions Autoformatter <autoformat@example.com> Co-authored-by: Rui Marinho <me@ruimarinho.net>
* [CI] Remove the template explosion in the CI via a matrix This PR is a continuation of #15334 the removes the exact same problem but with the iOS device tests rather than with the android tests. Uses the exact same approach, moves from using a template explosion to a matrix with the diff combinations. * Lower case looks much better.
# Conflicts: # Microsoft.Maui-mac.slnf # eng/AndroidX.targets # eng/Versions.props # eng/devices/android.cake # eng/devices/ios.cake # eng/pipelines/common/device-tests.yml # eng/pipelines/common/ui-tests.yml # src/Controls/samples/Controls.Sample.UITests/MauiProgram.cs # src/Controls/tests/UITests/Controls.AppiumTests.csproj # src/Core/src/Handlers/ViewHandlerExtensions.iOS.cs # src/TestUtils/src/TestUtils.Appium.UITests/AppiumQuery.cs # src/TestUtils/src/TestUtils.Appium.UITests/AppiumUITestApp.cs # src/TestUtils/src/TestUtils.Appium.UITests/TestUtils.Appium.UITests.csproj # src/TestUtils/src/TestUtils.Appium/TestConfig.cs # src/TestUtils/src/TestUtils.Appium/TestUtils.Appium.csproj
@mattleibow what did I do wrong here? seems it's adding all the same commits again . The file changes seem correct, but why does it show the old commits? the other merges were all "merge" not squash should they already be there on net8.0 ? |
* Fix tests * Don't use /tl
rmarinho
commented
May 31, 2023
* Add Legacy Control gallery slnf * - add missing blazor projects * - ignore frame tests * - ignore on iOS * - last set of failing uitests * - additional iOS ignores
This reverts commit 6fddcbe.
Eilon
added
the
area-infrastructure
CI, Maestro / Coherency, upstream dependencies/versions
label
Jun 1, 2023
Bumps Xamarin.UITest from 4.1.3 to 4.1.4. --- updated-dependencies: - dependency-name: Xamarin.UITest dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
jonathanpeppers
approved these changes
Jun 1, 2023
rmarinho
added a commit
that referenced
this pull request
Jun 2, 2023
### Description of Change Update preview 5 with latest main and net8 changes We need to merge the other first #15367
samhouts
added
the
fixed-in-8.0.0-preview.5.8529
Look for this fix in 8.0.0-preview.5.8529!
label
Aug 2, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
area-infrastructure
CI, Maestro / Coherency, upstream dependencies/versions
fixed-in-8.0.0-preview.5.8529
Look for this fix in 8.0.0-preview.5.8529!
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Change
Yet another merge of main to net8