Assigning to Deryk to assign.

I think this is likely an application issue. Chrome does complain about a few things that it "fixes" for us but it doesn't look good. It may not occur on the initial load of the page, but subsequent interaction/reloads do seem to show it. Attaching a screenshot for clarity.

Issues that Chrome is reporting but, perhaps, automatically "fixing" for us.

Can you take a look, maybe we're injecting more than one body tag via the dynamic includes, etc.

It would appear that the <f:view locale="#

" contentType="text/html"> contextType is causing chrome grief. Once removed the page render without any errors, I'll to a little more testing and check in the modified code.

I chatted with Mark about the behaviour and couldn't come up with a good reason for the behaviour, likely just some strange browser bug. If we see something like this I guess we could create little test program to see see what the raw HTML looks like on the initial response.

Resolving issue, code has been checked in.

This change appears to break rendering completely on chrome and Safari on the Mac.

Assigned to Ken for either reproduction by QA or assignment.

I set the contentType in the f:view back to text/html as WebKit browsers get borked if that's not set.

The fix to get WebKit browsers to not complain was to rationalize the link tags so that:

1) Any </link> tags are removed as links should be self terminated (since they don't have children). I changed the static links in the markup as well as the dynamically generated link in the StyleBean.
2) The h:output text was changed to an ice:outputText with nospan=true to avoid rendering a span.