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

Dynamic input field type renders invalid code in IE11 #8379

Open
nirazul opened this issue Jun 19, 2018 · 5 comments
Open

Dynamic input field type renders invalid code in IE11 #8379

nirazul opened this issue Jun 19, 2018 · 5 comments

Comments

@nirazul
Copy link

nirazul commented Jun 19, 2018

Version

2.5.17-beta.0

Reproduction link

https://github.com/nirazul/vue-loader-bug-repro

Steps to reproduce

  1. npm install
  2. npm run build
  3. npm run watch
  4. Open ./public/index.html
  5. Inspect main.bundle.js in dev tools
  6. On line 9044 you will find a duplicated key value

What is expected?

A valid output from vue-template-compiler without duplicated value props, or at least a warning that the usage of dynamic input field types is prohibited in certain cases.

What is actually happening?

In IE11 a blank page is rendered


I'm using a centralized component for both radio and checkbox input fields as the markup is 90% the same.
As we switched from webpack 3 to webpack 4, we had to also upgrade the vue-loader version from 12 to 13 or 14, which introduced this bug.
Prior to version 13, vue-template-renderer was not enforcing strict mode on all of its rendered templates. This is now the case, introducing this critical bug.

References:
https://vuejs.org/v2/guide/forms.html#Radio-1
#7048
#6917

@nirazul nirazul changed the title Dynamic input field type renders invalid code in IE11 when in es5 strict mode Dynamic input field type renders invalid code in IE11 Jun 19, 2018
@haoqunjiang
Copy link
Member

See discussions here: #7406

In this case, we are more likely to patch code generation to suppress :value emission when both type is dynamic and v-model is set. Thanks for pointing out!

@nirazul
Copy link
Author

nirazul commented Jun 20, 2018

@sodatea
Thanks for the clarification. I agree that :value suppression would be the right way to go with that.

@ollietreend
Copy link

I've just experienced this exact same 'white screen' issue with IE11, whereas no warnings or problems were experienced in modern browsers (Chrome, Firefox, Safari, Edge).

The IE11 JS console showed the following error:

Multiple definitions of a property not allowed in strict mode

I jumped down the rabbit hole and followed a few threads between different issues and PRs here, but struggled to find a clearly documented solution. After some trial and error, I've come up with something that works for my needs.

For the benefit of others in the same situation, this is the solution I've come up with:

Solution

Originally I'd bound the input type attribute to a variable, which would either be checkbox or radio:

<input :type="type" :value="value" v-model="model" />

Since the issue seems to stem from dynamically binding the type attribute, I changed my template to conditionally render the input using v-if:

<input v-if="type === 'checkbox'" type="checkbox" :value="value" v-model="model" />
<input v-if="type === 'radio'" type="radio" :value="value" v-model="model" />

By hardcoding the type attribute for each of the possible types, and showing them conditionally depending on the value of type, I was able to workaround this particular bug. IE11 seems to be fine with this.

ollietreend added a commit to jac-uk/digital-platform that referenced this issue Mar 5, 2019
This commit fixes #36 – an IE11 bug which caused a 'white screen of death' as the page failed to render.

The cause of this bug is discussed in vuejs/vue#8379. To summarise: the use of dynamically bound `type` attributes on `<input>` elements compiles into bad JS output, which chokes IE11.

Dynamic `type` binding was used in the `SelectList` component to render either a radio or checkbox input (depending on the value of the `multiple` property). To work around this limitation, I've split both potential input types (a radio input and a checkbox input) into their own elements, and conditionally show/hide them with `v-if`. This produces different JS output which keeps IE11 happy.
ollietreend added a commit to jac-uk/digital-platform that referenced this issue Mar 5, 2019
This commit fixes #36 – an IE11 bug which caused a 'white screen of death' as the page failed to render.

The cause of this bug is discussed in vuejs/vue#8379. To summarise: the use of dynamically bound `type` attributes on `<input>` elements compiles into bad JS output, which chokes IE11.

Dynamic `type` binding was used in the `SelectList` component to render either a radio or checkbox input (depending on the value of the `multiple` property). To work around this limitation, I've split both potential input types (a radio input and a checkbox input) into their own elements, and conditionally show/hide them with `v-if`. This produces different JS output which keeps IE11 happy.
ollietreend added a commit to jac-uk/digital-platform that referenced this issue Mar 5, 2019
This commit fixes #36 – an IE11 bug which caused a 'white screen of death' as the page failed to render.

The cause of this bug is discussed in vuejs/vue#8379. To summarise: the use of dynamically bound `type` attributes on `<input>` elements compiles into bad JS output, which chokes IE11.

Dynamic `type` binding was used in the `SelectList` component to render either a radio or checkbox input (depending on the value of the `multiple` property). To work around this limitation, I've split both potential input types (a radio input and a checkbox input) into their own elements, and conditionally show/hide them with `v-if`. This produces different JS output which keeps IE11 happy.
@4refael
Copy link

4refael commented Jun 19, 2019

Just spent a few hours trying to debug the same issue.
This is still an issue in v2.6.10..

@rs3d
Copy link

rs3d commented Dec 27, 2019

I've also spend now some time debugging this on a async module, which complicated the bug search a lot. It would be great to have this fixed <3

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

No branches or pull requests

5 participants