Inline <script type="text/markdown"> not picked up in ready()

[brettpostin]

Description

TL;DR

var markdownElement = Polymer.dom(this).querySelector('[type^="text/markdown"]');

In Chrome, this line in the ready() callback returns null unexpectedly.

Long Version

Ok I've tried to reproduce this in isolation but I'm having difficulty so I will have to try and explain as best I can.

Environment:

• Heavily developed instance of the Polymer Starter Kit for an internal element gallery.
• Polymer 1.8.1 using webcomponents-lite.js and shady dom.

Markup:

<paper-material>
    <p>A horizontal layout:</p>
    <my-layout orientation="horizontal">
        <my-pane></my-pane>
        <my-pane></my-pane>
        <my-pane></my-pane>
    </my-layout>
    <marked-element id="1">
        <script type="text/markdown">
            ```
            TEST 1
            ```
        </script>
    </marked-element>
    <marked-element id="2">
        <script type="text/markdown">
            ```
            TEST 2
            ```
        </script>
    </marked-element>
</paper-material>
<paper-material>
    <p>A horizontal layout:</p>
    <my-layout orientation="horizontal">
        <my-pane></my-pane>
        <my-pane></my-pane>
        <my-pane></my-pane>
    </my-layout>    
    <marked-element id="3">
        <script type="text/markdown">
            ```
            TEST 3
            ```
        </script>
    </marked-element>
    <marked-element id="4">
        <script type="text/markdown">
            ```
            TEST 4
            ```
        </script>
    </marked-element>
</paper-material>

Given four marked-elements with the exact same markup (copied-pasted) , the 3rd marked-element does not render at all. I have put the following tracing in:

In the ready() method the following line unexpectedly returns null:

var markdownElement = Polymer.dom(this).querySelector('[type^="text/markdown"]');

Observations:

• It only happens in Chrome. IE, Edge and Firefox all exhibit the expected behaviour.
• It appears to be a timing issue. Attaching the debugger seems to give Chrome a chance to catch up and it works as expected.
• It seems to be sensitive to the surrounding markup, removing different portions of surrounding markup changes which marked-element (1,2,3,4) does not get rendered.

Expected outcome

All marked-elements get rendered.

Actual outcome

A pseudo-random marked-element does not get rendered, seemingly dependent on the rest of the document.

Browsers Affected

• [ x ] Chrome
• Firefox
• Safari 9
• Safari 8
• Safari 7
• Edge
• IE 11
• IE 10

[stramel]

@brettpostin what version of the marked-element are you using? I'm not able to reproduce https://jsfiddle.net/stramel/qfbwsLj6/

[brettpostin]

Originally 1.3.1, however I have just updated to 1.4.1 and still see the issue.

As mentioned above I'm struggling to reproduce this with the markup above in isolation. As it seems to be affected by other elements in the document, I'm wondering if another (our badly implemented) element could be interfering with the shady dom in some way?

But then it's strange that it only happens in Chrome...

[brettpostin]

For reference, the only other markup inside the body is the following:

<prism-highlighter></prism-highlighter>

<my-layout id="fulldemo-layer1" orientation="horizontal">
	<my-pane size="100px">
		<div>Size = 100px</div>
	</my-pane>
	<my-pane>
		<my-layout id="fulldemo-layer2" orientation="vertical">
			<my-pane min-size="50px" max-size="100px">
				<!--<div>Min size = 50px</div>
				<div>Max size = 100px</div>-->
			</my-pane>
			<my-pane scrollable="true">
				<!--<div id="fulldemo-content">
					<my-button text="Close" onclick="closeFullDemo()"></my-button>
				</div>-->
			</my-pane>
			<my-pane size="50px">
				<!--<div>Size = 50px</div>-->
			</my-pane>
		</my-layout>
	</my-pane>
	<my-pane min-size="100px" max-size="200px">
		<div>Min size = 100px</div>
		<div>Max size = 200px</div>
	</my-pane>
</my-layout>

Something as simple as commenting out the two <div> tags in the bottom pane seemingly changes the behaviour, making all 4 marked-elements render as expected.

Uncommenting out various other portions can change which of the four marked-elements does not render.

Confused!

[stramel]

@brettpostin Can you try out the latest version? I think it may have been some kind of timing issue that should be resolved with the MutationObserver that @e111077 added.

[brettpostin]

Updated to 2.1.0 and afraid it didn't help.

I did try stripping everything back in our app and it was still evident so I will have another go at reproducing it in an isolated environment.