Bug 174629 - Release assert when using paper-textarea due to autocorrect IDL attribute missing CEReactions
Summary: Release assert when using paper-textarea due to autocorrect IDL attribute mis...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Bindings (show other bugs)
Version: Safari 10
Hardware: iPhone / iPad iOS 10.3
: P2 Blocker
Assignee: Ryosuke Niwa
Keywords: InRadar
Depends on:
Blocks: 154907
  Show dependency treegraph
Reported: 2017-07-18 08:06 PDT by Marc Bornträger
Modified: 2018-09-24 16:10 PDT (History)
11 users (show)

See Also:

Reduction (241 bytes, text/html)
2018-09-21 23:19 PDT, Ryosuke Niwa
no flags Details
Fixes the bug (4.41 KB, patch)
2018-09-22 02:11 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Bornträger 2017-07-18 08:06:33 PDT
Original issue:
- https://github.com/PolymerElements/paper-input/issues/556
- https://github.com/hotforfeature/origami/issues/38

Our app gets called in two separate ways:
1. Like a normal web page through Google chrome
2. Through our native iOS app with WkWebView

So our approach was to build only a native app for iOS to fill the gaps of the ServiceWorker (like to enable push notifications, offline support, etc.). Which Safari, obviously doesn't have but chrome does.

On Google chrome (all versions) the app works without issues.
And on our Safari native app the web app crashes. Total crash happens without error message. So screen just gets blank.

We are using Angular and Polymer together. So this is why this issue came up -> **it only happens if a web component is created via** `document.createElement()`. So programmatically. Which Angular always does.

This is the browser version of WkWebView (verified with http://www.whoishostingthis.com/tools/user-agent/): `Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Mobile/14F89`

This is how we instantiate the paper-textarea:
<paper-textarea label="test" id="newMessage" name="newMessage"></paper-textarea>

The issue is only with paper-textarea. paper-input works perfectly

### Expected outcome

<!-- Example: The page stays the same color. -->

The app get's loaded correctly over WKWebView. Maybe there is something that `paper-textarea` does, which messes up the loading on WKWebView.

### Actual outcome

<!-- Example: The page turns pink. -->

# The Problem
Adding the <paper-textarea> to index.html was fine, but the Angular DefaultDomRenderer2 could not create it without throwing the error "A newly constructed custom element must not have attributes".

This is the cause for things breaking. While `document.createElement()` lets you continue, the element it returns is actually an `HTMLUnknownElement`, and so naturally it doesn't open its Shadow DOM from extending `Polymer.Element`.

# Raw vs Programmatic Element Creation

There are two ways to "create" an element: raw HTML and programatically. A Polymer project goes through raw HTML. It provides it directly to the browser to render.

Angular does things programmatically and calls `document.createElement()`. This is why you can do weird things like `<paper-item class$="[[binding]]">` in Polymer but not Angular. `class$` is not a valid attribute and throws an error when calling `element.setAttribute('class$', '[[binding]]')`.

# Not Just Angular!
So far, all the tests have just been isolated on `<paper-textarea>`. I'm testing with both this element and `<paper-input>`, since they're similar. `<paper-input>` is perfectly chill with `document.createElement()`.

I've ruled out Origami as the problem, so I thought maybe something with zone.js or the reflect shim was adding attributes at element creation. I decided to turn to pure Polymer and take both of these and any other weird Angular shenanigans out of the picture.


This is the demo file that we should navigate to within the `WKWebView`. It'll load up just fine and `<paper-textarea>` works. Inspect the console and run the following:

window.onerror = function(err) { debugger; console.log('error', err) };
var ele = document.createElement('paper-textarea');
console.log(ele instanceof HTMLUnknownElement);
console.log(ele instanceof customElements.get('paper-textarea'));


[Log] error – "NotSupportedError (DOM Exception 9): A newly constructed custom element must not have attributes"
[Error] NotSupportedError (DOM Exception 9): A newly constructed custom element must not have attributes
	Console Evaluation (Console Evaluation 4:3)
[Log] true
[Log] false

# Thoughts
When creating a small component such as:
<dom-module id="paper-wrapped">
    <paper-textarea value="{{value}}"></paper-textarea>
      is: 'paper-wrapped',
      properties: {
        value: {
          type: String,
          notify: true      
The whole concept works without problems. The website can be called via WKWebView.

We have ruled out the problem with the word "textarea". We thought maybe WKWebView sees that and is adding some textarea-specific attributes when it shouldn't be. But we tried it with this repo: https://github.com/BorntraegerMarc/paper-input which did not work as well.

### Live Demo
<!-- Example: https://jsbin.com/cagaye/edit?html,output -->
* https://github.com/kmyllyvi/WKWebViewTester
* https://github.com/BorntraegerMarc/polymer-chat
* https://raw-dot-custom-elements.appspot.com/PolymerElements/paper-input/v2.0.0/paper-input/demo/index.html

### Steps to reproduce

<!-- Example
1. Put a `paper-foo` element in the page.
2. Open the page in a web browser.
3. Click the `paper-foo` element.

We ran the following tests:
1. We generated a normal polymer project with Polymer starter kit and everything worked as excpected. So the error only comes up if angular (or origami) is included
2. We created this minimal origami project: https://github.com/BorntraegerMarc/polymer-chat and the WKWebView crashes at the exact same component. Because of this: https://github.com/BorntraegerMarc/polymer-chat/blob/master/src/app/message/input/message-input.component.html#L3
3. If you completely comment out the `paper-textarea` component from the HTML it works without issue. So the TS reference `@ViewChild('messageInput')` has no influence on it. when we commented out `@ViewChild` the same issue persisted. Ony when commenting out the HTML code the app started to work again.

For easy testing purposes we created the following iOS native app project: https://github.com/kmyllyvi/WKWebViewTester you can just clone & run it.
Which is just a WKWebView project. How to test:
1. Clone and install the minimal origami project
2. Clone and install the WKWebView project
3. Start angular with ng serve
4. Start the ios app project on an iPhone simulator and navigate to http://localhost:3000 (you can enter the URL in the actual app)

### Browsers Affected
<!-- Check all that apply -->
- [ ] Chrome
- [ ] Firefox
- [X] WKWebView on all safari versions
- [ ] Safari 9
- [ ] Safari 8
- [ ] Safari 7
- [ ] Edge
- [ ] IE 11
- [ ] IE 10
Comment 1 Radar WebKit Bug Importer 2017-07-19 11:44:16 PDT
Comment 2 Simon Fraser (smfr) 2017-07-24 18:56:48 PDT
You'll have to give us an actual test app for us to be able to debug this.
Comment 3 Marc Bornträger 2017-07-24 22:53:19 PDT
Thanks for the reply @Simon Fraser. I have included two test apps: One for the web frontend and one for the WKWebView app. With these two projects it should be perfectly reproducible. Do you need anything else?
Comment 4 Marc Bornträger 2017-07-24 22:54:06 PDT
With "included" I mean I have published the code on GitHub and posted the URL in the description. Not as attachment in the comments.
Comment 5 Simon Fraser (smfr) 2017-07-25 08:38:11 PDT
Sorry, I missed that you had github example (there are a lot of words in the report).
Comment 6 Marc Bornträger 2017-07-25 09:25:12 PDT
Just trying to give an accurate report :)
Comment 7 Marc Bornträger 2017-08-21 13:51:24 PDT
FYI: if you wrap the component with all attributes, it still does not work. The property `autocorrect` seems to be causing the problem. Only if you remove that one property in the wrapped component it seems to work. (you don't even need to use the attribute in your element. It's already enough to provoke the crash if `autocorrect` is defined as an attribute)
Comment 8 Ryosuke Niwa 2017-08-21 14:52:50 PDT
That exception will be thrown if you're trying to add an attribute inside your custom element's constructor per specification.
Comment 9 Ryosuke Niwa 2017-08-21 15:04:21 PDT
Could you create a simple HTML file which reproduces the issue inside a WKWebView? I really can't follow various instructions and comments you've posted.
Comment 10 Marc Bornträger 2017-08-22 05:13:56 PDT
sure. It can be hard to read as this website does not allow formatting. For a easier read I have also published the issue here: https://github.com/PolymerElements/paper-input/issues/556

Regarding the HTML file: You can take the HTML content from this site: https://raw-dot-custom-elements.appspot.com/PolymerElements/paper-input/v2.0.0/paper-input/demo/index.html

Unfortunately it's not very easy to publish a single HTML file as I don't really know where the issue is. So we need to define couple of dependencies like Polymer, etc. to reproduce it. But I hope the URL above helps a bit.
Comment 11 Paulus Schoutsen 2018-08-16 08:25:11 PDT
It can be reproduced with the following HTML snippet:

<script type='module'>
  import 'https://unpkg.com/@polymer/paper-input@3.0.0-pre.21/paper-textarea.js?module';

Also published as CodePen: https://codepen.io/anon/pen/ejwMNN
Comment 12 Ryosuke Niwa 2018-09-21 23:19:58 PDT
Created attachment 350499 [details]

Huh, this causes a crash in MobileSafari on iOS 12 simulator...
Comment 13 Ryosuke Niwa 2018-09-21 23:53:36 PDT
Wow, it still crashes on trunk. This is because "autocorrect" IDL attribute on HTML element is missing CEReactions.
Comment 14 Ryosuke Niwa 2018-09-22 02:11:15 PDT
Created attachment 350507 [details]
Fixes the bug
Comment 15 Paulus Schoutsen 2018-09-22 02:53:34 PDT
Thank you!
Comment 16 Ryosuke Niwa 2018-09-24 16:10:04 PDT
Comment on attachment 350507 [details]
Fixes the bug

Clearing flags on attachment: 350507

Committed r236439: <https://trac.webkit.org/changeset/236439>
Comment 17 Ryosuke Niwa 2018-09-24 16:10:06 PDT
All reviewed patches have been landed.  Closing bug.