Skip to content
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

Doesn't load template page in IE11 #387

Open
chrjanop opened this issue Oct 15, 2019 · 12 comments · Fixed by aurelia/cli#1161
Open

Doesn't load template page in IE11 #387

chrjanop opened this issue Oct 15, 2019 · 12 comments · Fixed by aurelia/cli#1161

Comments

@chrjanop
Copy link

I'm submitting a bug report

  • Library Version:
    2.0.0-rc.8

Please tell us about your environment:

  • Operating System:
    Windows 10

  • Node Version:
    8.12.0

  • NPM Version:
    6.4.1
  • JSPM OR Webpack AND Version
    webpack 4.41.1
  • Browser:
    IE 11

  • Language:
    ESNext

Current behavior:
Just a white blank page when I open the template app in IE11.

Steps to reproduce:
√ Please enter a name for your new project: · aurelia-app
√ Would you like to use the default setup or customize your choices? · Custom App
√ Which bundler would you like to use? · Webpack
√ Which HTTP Protocol do you wish the outputted Webpack bundle to be optimised for? · HTTP/2
√ What platform are you targeting? · Web
√ What transpiler would you like to use? · Babel
√ How would you like to setup your HTML template? · None
√ What css preprocessor would you like to use? · None
√ Do you want to add PostCSS processing · None
√ Which unit test runner would you like to use? · Jest
√ Would you like to configure integration testing? · None
√ What is your default code editor? · None
√ Which features do you want scaffolded into your project? · Navigation App
√ Would you like to add a Dockerfile? · No
Then install npm dependencies

npm install aurelia-dialog --save
Then add aurelia.use.plugin(PLATFORM.moduleName('aurelia-dialog')); to main.js

Open internet explorer 11, type localhost:8080 and observe you're not seeing the template.
Works well on chrome, firefox, edge.

  • What is the expected behavior?
    Be able to see the template, load the welcome page in IE11

Note: Version 1.1.0 works.

@y2k4life
Copy link

I'm going to assume this is similar to my issue.
More specifically this is 'Promise' is undefined. Might I suggest changing the title?

I have a similar setup but I'm using

Library Version: 2.0.0

image

Here is a converstaion on Discourse

It seems as if Webpack Runtime gets to a point where the promise-polyfill seem to be no longer present. The irony though is that when the error is thrown it is caught by code in the promise-polyfill. At first I thought this was due to loading async chunks in WebPack. Once I got WebPack to bundle all of aurlie-dialog into a single chunk there was still a Promise undefined error just in a different place.

I have tried everything to get the promise-polyfill loaded before the run time. Move it to entry, create vendor entry, have it as a plugin and an entry, put import 'promise-polyfill' everywhere.

But the question is why at times the Promise is defined and other times it is not. But still puzzled as to why I would need to do to get promise-polyfill loaded first if the stack trace returns back to promise-polyfill. If it returns back to there then it had to be loaded before the run time in order to start from there. You then think Promise would be defined. IDK grasping for straws.

A solution is to put the following line in the index.ejs but that seems to be against the grain.

<script src="https://cdn.jsdelivr.net/npm/[email protected]/lib/index.min.js"></script>

In aurelia-dialog this is where it starts

dialog/src/ dialog-configuration.ts
  private _apply(): Promise<void> {
    const renderer = this.renderer;
    const cssText = this.cssText;
    return Promise
      .all([
---->        typeof renderer === 'string' ? RENDERRERS[renderer]() : renderer,
        cssText
          ? typeof cssText === 'string'
            ? cssText
            : cssText()
          : ''
.
.
.

Which then calls ux: () => from the RENDERRERS.

const RENDERRERS: Record<string, () => Promise<RendererStatic>> = {
  ux: () => import('./renderers/ux-dialog-renderer').then(m => m.DialogRenderer) as Promise<RendererStatic>,
.
.

The above is compiled to this

ux: function () { return __webpack_require__.e(/*! import() */ "vendors.async~3e799143").then(__webpack_require__.bind(null, /*! ./ux-dialog-renderer.js */ "yfWE")).then(function (m) { return m.DialogRenderer; }); },

Which then calls the WebPack run time to resolve vendors.async~3e799143

__webpack_require__.e = function requireEnsure(chunkId) {
/******/ 		var promises = [];
/******/
/******/
/******/ 		// JSONP chunk loading for javascript
/******/
/******/ 		var installedChunkData = installedChunks[chunkId];
/******/ 		if(installedChunkData !== 0) { // 0 means "already installed".
/******/
/******/ 			// a Promise means "currently loading".
/******/ 			if(installedChunkData) {
/******/ 				promises.push(installedChunkData[2]);
/******/ 			} else {
/******/ 				// setup Promise in chunk cache
/******/ 				var promise = new Promise(function(resolve, reject) {
/******/ 					installedChunkData = installedChunks[chunkId] = [resolve, reject];
/******/ 				});
/******/ 				promises.push(installedChunkData[2] = promise);

It dies at // setup Promise in chunk cache when creating a new Promise
var promise = new Promise(function(resolve, reject) ....

But then you continue and you end up in the promise-polyfill try … catch

   try {
      ret = cb(self._value);
    } catch (e) {
      reject(deferred.promise, e);
      return

@y2k4life
Copy link

y2k4life commented Feb 18, 2020

Thanks to @3cp we have a solution!

To me this is a documentation bug. Some where it needs to be noted that these changes need to be made in order for aurelia-dialog 2.0 to work with IE11.

To fix this issue you need to add the following alias under the Resolve section of webpack.config.js

'aurelia-dialog': path.resolve(__dirname, 'node_modules/aurelia-dialog/dist/umb/dialog-aurelia.js')

Here is an example of what the Resolve section should look like after a clean setup.

  resolve: {
    extensions: ['.ts', '.js'],
    modules: [srcDir, 'node_modules'],
    // Enforce single aurelia-binding, to avoid v1/v2 duplication due to
    // out-of-date dependencies on 3rd party aurelia plugins
    alias: { 'aurelia-binding': path.resolve(__dirname, 'node_modules/aurelia-binding') },
    alias: { 'aurelia-dialog': path.resolve(__dirname, 'node_modules/aurelia-dialog/dist/umd/dialog-aurelia.js') }
  },

@3cp
Copy link
Member

3cp commented Feb 18, 2020

Your two aliases should be just one alias with two keys. I am surprised nodejs didn't complain about the duplicated object key (alias) in your webpack config.

@y2k4life
Copy link

y2k4life commented Feb 18, 2020

Good catch something like this

alias: {
  'aurelia-binding': path.resolve(__dirname, 'node_modules/aurelia-binding'),
  'aurelia-dialog': path.resolve(__dirname, 'node_modules/aurelia-dialog/dist/umd/dialog-aurelia.js')
}

@3cp
Copy link
Member

3cp commented Feb 18, 2020

aurelia-dialog v1 uses aurelia-loader (the abstration layer normalized module loaders) to load dynamic resources.

v2 switched to native dynamic import() statement to simplify the code. This is indeed a breaking change for IE11.

However the dialog UMD build did normalize import() to plain promise. By default, it should work on IE11.

But our aurelia-webpack-plugin tries to load all aurelia-* packages native-modules build in order to take advantage of some webpack features. For example, webpack can tree-shake esm format, but cannot tree-shake js code in other format. So it did not pick the good old aurelia-dialog UMD build.

In summary, IE should die :-)

y2k4life added a commit to y2k4life/documentation that referenced this issue Feb 18, 2020
@3cp explains the issue here [Issue 387](aurelia/dialog#387) and here on [discourse](https://discourse.aurelia.io/t/ie11-dialog-promise-undefined/3240/16)

> v2 switched to native dynamic import() statement to simplify the code. This is indeed a breaking change for IE11.
@3cp
Copy link
Member

3cp commented Feb 20, 2020

Please review the above cli PR (will be released in couple of days).
This one can be closed.

@y2k4life
Copy link

I just did a review and found that the alias is not needed. Going back to what we did earlier when we put the promise-polyfill in index.ejs with a <script> tag it worked.

I'm going to assume that the changes to the promise-polyfill in webpack.config.js resulted in something similar to putting the polyfill into index.ejs.

I did a check by keeping the comments on the alias and it works. I also see in the IE11 debugger the native modules being loaded.

My only other suggestion is to keep the messaging consistent. One section it is commented out stating to Uncomment if using IE11 and the other section is not commented stating if you don't use IE11 to comment. Not that it matters because the alias is not needed I would suggest to just comment out the promise polyfill and have the message Uncomment if using IE11.

If this works with the promise-polyfill moved in the webpack.config.js then the alias and my PR for document changes are not needed.

@3cp
Copy link
Member

3cp commented Feb 20, 2020

Yes, it worked without the alias, but I saw many strange WDS error in IE11 console. That could be due to the webpack transpiled import() is not compatible with polyfilled promise. Please double check that.

@y2k4life
Copy link

Either way it will work. I have been working with my app with just the promise-polyfill change without any issues. I think the [WDS] Disconnect! error is a webpack-dev-server issue. The only time I have seen them in IE11 is when I stop the webpack-dev-server but leave the browser open. Then some times when I start WDS up the error continues to show in IE11. Furthermore I don't see them when I run the app using IIS Express or Kestral (My app is .Net) obviously because I'm not using webpack-dev-server at that time. I still stick with the idea that the alias is not needed and documentation does not need to change, just the way promise-polyfill is loaded.

@3cp
Copy link
Member

3cp commented Feb 21, 2020

Thanks for the inside. I thought those WDS errors was caused by import() chunks.

Let's keep the alias in CLI, it's by default behind comment (doesn't hurt much), so that users can still have something to try if they have other problems in IE11. This is just to be cautious, the import() might cause user some other issue if they adjust code split settings in webpack (but I am not a webpack expert to be certain).

@3cp
Copy link
Member

3cp commented Feb 21, 2020

is not needed I would suggest to just comment out the promise polyfill and have the message Uncomment if using IE11.

I will do that, that sounds a good default.

@y2k4life
Copy link

y2k4life commented Feb 21, 2020

It was funny because I was thinking "What is this WDS". When I started to type Webpack-Dev-Server the light bulb went on. That and searching for WDS all results pointed to Webpack which I found odd at first until I realized what WDS is.

Always good to be cautions especially when it comes to dated browsers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants