Open BorntraegerMarc opened 7 years ago
Many thanks to @hotforfeature for the analysis! This is the original issue: https://github.com/hotforfeature/origami/issues/38
Also filed a bug for apple: https://bugs.webkit.org/show_bug.cgi?id=174629
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)
I ran into this exact same crashing issue using jQuery .append() on paper-textarea
. For me it happens iOS devices in both Safari and Chrome. Using paper-input
instead of paper-textarea
is the only workaround I have found that fixes it.
I followed the fix of this last merge (wrapping paper-textarea in another element) and it worked. Thank you.
Description
Our app gets called in two separate ways:
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:
The issue is only with paper-textarea. paper-input works perfectly
Expected outcome
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
The Problem
Adding the 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 anHTMLUnknownElement
, and so naturally it doesn't open its Shadow DOM from extendingPolymer.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 callingelement.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 withdocument.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.
https://raw-dot-custom-elements.appspot.com/PolymerElements/paper-input/v2.0.0/paper-input/demo/index.html
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:Output:
Thoughts
When creating a small component such as:
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
Steps to reproduce
We ran the following tests:
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:
Browsers Affected