[macOS] HTMLLoader doesn't work with Apple Silicon M1 ARM CPUs devices

itlancer commented 3 years ago

Problem Description

HTMLLoader doesn't work with Apple Silicon M1 ARM CPUs macOS devices. Tested with latests AIR 33.1.1.575 with multiple macOS Big Sur Apple Silicon M1 ARM CPUs devices with different applications. Same problem in all cases.

It works fine with Intel-based macOS devices. Also it works fine with Windows devices.

This issue blocks HTMLLoader usage at all.

Steps to Reproduce

Package bundled macOS AIR application using code below launch it with Apple Silicon M1 ARM CPUs macOS device. Note: may be you cannot use IDE to launch that because of issue https://github.com/airsdk/Adobe-Runtime-Support/issues/1092

Application example with sources attached. macos_htmlloader_bug.zip

package {
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.html.HTMLLoader;
    import flash.net.URLRequest;

    public class MacOSHTMLLoaderBug extends Sprite {
        private var htmlLoader:HTMLLoader;

        public function MacOSHTMLLoaderBug() {
            htmlLoader = new HTMLLoader();
            htmlLoader.width = 640;
            htmlLoader.height = 480;
            addChild(htmlLoader);

            htmlLoader.load(new URLRequest("https://google.com"));
        }
    }
}

Actual Result: Runtime error will be thrown:

Exception: flash.html::ControlInitializationError
    flash.html::HTMLLoader/initHTMLEngine
    flash.html::HTMLLoader
    MacOSHTMLLoaderBug
    runtime::ContentPlayer/loadInitialContent
    runtime::ContentPlayer/playRawContent
    runtime::ContentPlayer/playContent
    runtime::AppRunner/run
    AppEntryCommon/run
    global/runtime::ExtendedAppEntry
    global/runtime::CaptiveAppEntry

Website (specified URL) cannot be loaded and shown.

Expected Result: Application correctly load and show specified URL.

Known Workarounds

none

rogerclarkmelbourne commented 3 years ago

@itlancer

I'm getting bug reports that Capabilities.os on machines running on Apple Silcon return a string suggesting the OS is iOS

Specifically "iPhone OS 14.4 ipad8,6" instead of some Mac OS version like "Mac OS 11.5.1" (or whatever version is used by Apple Silicon machines)

I'm currently trying to confirm whether this is actually the case but I don't have an Apple Silicon machine, so I'm unable to test this.

ajwfrost commented 3 years ago

@rogerclarkmelbourne it should depend what you're running, as much as what you're running on. So if you take an application that was created using the IPA target type, it will include the AIR build for ios and hence that sort of string can be used - although we can check whether it's possible to update it. If you do run an application on a Mac using ADL or when built as a bundle, then it will include the desktop runtime build which is working fine (I just get "Mac OS 12.0.0" when I trace the Capabilities.os here)

@itlancer the problem with HTMLLoader is that the app doesn't know in advance that you'll be trying to load webkit, and we don't have an ARM build of webkit. So:

Adobe AIR: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
Adobe AIR (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64
Adobe AIR (for architecture arm64):     Mach-O 64-bit dynamically linked shared library arm64

vs

WebKit.dylib: Mach-O 64-bit dynamically linked shared library x86_64

If you have an application that you can configure to always use Rosetta then it should work; we're looking to see what sort of workarounds may be possible to try to make this automatic..

thanks

rogerclarkmelbourne commented 3 years ago

@ajwfrost Perhaps I should start a new issue...

I'm building using adobe CC on the Mac, with the runtime embedded.

When I tested on MacOS 11.5 its reporting Mac OS 16.10

The application logs the Capabilities.os as part of its normal operation and sends this to the server along with the user's own specific data, so we can fault find when a user has problems.

In this case , the user says they are using a Mac, but the log files for that user have a Capabilities.OS which seems to be the string for iOS14

i.e I've tested on an iPad running iOS 13 and the Capabilities.os string is virtually the same except this Mac user's machine is spitting out that they are running iOS14 on a iPad 8,6 (whatever that means)

We presumed that the Capabilities.os must be being read from the environment on the Mac, and if it's a Apple Silicon, it must be running the x86 code via some sort of emulation or virtual machine. Hence if the Capabilities.os is comming from the VM, then potentially the VM is giving that value to the AIR runtime.

Or perhaps its just flags the AIR runtime is reading, and you are building the string from those flags and values ?

ajwfrost commented 3 years ago

@rogerclarkmelbourne that's very odd .. yes worth opening a new issue, and I'm wondering if we can find out more from this customer to see what they're actually running. The code for the OS string is part of the runtime and for Mac is hardcoded to "Mac OS " and then a version string x.y.z which we get from NSProcessInfo.operatingSystemVersion (https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion) So I'm not sure how this is going wrong!

rogerclarkmelbourne commented 3 years ago

We are trying to find out whats going on.

The customer is insistant that they are running a Mac and we asked them to send us a screengrab, which has confiirmed they are running a Mac, so we've now asked for what hardware etc, but we don't think they are very technical and may not even know if its using Apple Silicon to x86 architecture.

All the log files indicate that its an iPad, but the screen grab from the mac looks like the CSS that is being downloaded and used for some StageWebView's inside the application looks like its our iPad CSS

We do build for PC, Mac and iPad, with unified souce and just check the Capabilities.os to determine which OS they are running on, if we need to load alternative data for that hardware

Hopefully they'll get back to us on Monday with more information.

In the mean time we're going to build a Mac version which doesn't use Capabilities.os to determine the hardware, and the code will use Config Contants instead, and we'll send that special version to the customer and see if the iPad layouts etc stop happening on their Mac

Thanks...

ajwfrost commented 3 years ago

One quick thought: do you deploy via the App Store? It may be you can install an iPad app on an M1 Mac, which would explain it...

rogerclarkmelbourne commented 3 years ago

No. It's not deployed though the App store becuase of a problem with using a ANE which Apple's validation won't accept due to the way the static library was compiled

Its deployed via an installer package

itlancer commented 3 years ago

If you have an application that you can configure to always use Rosetta then it should work; we're looking to see what sort of workarounds may be possible to try to make this automatic..

@ajwfrost, we cannot use Rosetta for whole application cause we already switch to some universal native extensions and I think it better for further development avoid Rosetta. Maybe only WebKit.dylib somehow could use Rosetta "under the hood"? Or it could be recompiled to support arm64? Ideally we need new webframe functionalities implementation for AIR. To support using it with DisplayList (or even Stage3D too) and with latest (may be native/system libraries from device) HTML5/CSS3 specifications. Right now HTMLLoader and StageWebView outdated and all alternative approaches with native extensions for that have some limitations.

rogerclarkmelbourne commented 3 years ago

@ajwfrost

FYI.

I've built a version which doesn't check the Capabilities.OS in order to determine the the OS, and uses a CONFIG constant instead

We've sent this version to the customer, but have yet to hear back from them.

I'll let you know if we ever get feedback on this, but sometimes the customers find it easier just to use the PC or iPad version instead.

itlancer commented 3 years ago

@ajwfrost And HTMLLoader.isSupported return true with Apple Silicon M1 ARM CPUs devices right now. So only way to check "does app real support HTMLLoader for macOS" - check Capabilities.cpuArchitecture for ARM value.

rogerclarkmelbourne commented 3 years ago

@ajwfrost

We had another report of Capabilities.os string reporting a Mac as an iPad

We've asked this customer to confirm their hardware, because the other customer who had the problem didn't reply to our questions :-(

paulweb2 commented 3 years ago

On a Mac M1 developing/debugging with IntelliJ IDEA an AIR/FLEX app using Harman Air SDK 33.1.1.674 overlaid on Flex SDK 4.16 results in '[Fault] exception, information=Error: HTMLLoader failed to initialize'.

Same set up works fine on an Intel Mac and the output AIR app can be installed and run using Rosetta on an M1.

Is this just never gonna work on an M1 and I should just stay developing on the Intel Mac and get M1 users to always run the app with Rosetta?

ajwfrost commented 2 years ago

Hi - currently this won't work because of the old WebKit library only supporting Intel. If you strip the arm64 variant out of your application's main executable, it will automatically use Rosetta on M1 and then load in the WebKit.

But we're about to push out a beta that will remove WebKit entirely, and just rely on the native OS to provide webview functionality - essentially like a StageWebView(true) object. The benefit of this is it will support the latest HTML5 standards; the downside is that we don't have the tight integration and control between AS3 and JavaScript/HTML any more. We can then see what integration people do actually need here, and provide some updated version of this using a better/more future-proof technology..

To clarify the proposed approach: the updated AIR runtime will still expose the HTMLLoader API but under the hood will use the native stagewebview; trying to create a StageWebView object will always create the native OS implementation. So for the vast majority of apps (and certainly the ones that Adobe use for the runtime and application installer dialogs etc) should just run fine on this without needing any changes...

thanks

paulweb2 commented 2 years ago

Thanks Andrew will wait for the update and see how things go with the native approach.

al-sabr commented 2 years ago

This thread can be connected with this also : #1438

itlancer commented 2 years ago

With latests AIR versions HTMLLoader deprecated and removed. So this issue not actual anymore. But WebKit files still in AIR application bundle https://github.com/airsdk/Adobe-Runtime-Support/issues/1882 Also HTMLLoader.isSupported still returns true https://github.com/airsdk/Adobe-Runtime-Support/issues/1881

airsdk / Adobe-Runtime-Support