Renderviz breaks the form action value. An example from the user login form:
<form class="user-login-form" data-drupal-selector="user-login-form" action="<!--RENDERER_START--><!--{"contexts":["languages:language_interface","theme","url.path","url.query_args","user.permissions"],"tags":[],"max-age":-1}--><!--{"tags":[],"max-age":-1,"contexts":["languages:language_interface","theme","user.permissions"]}-->/user/login<!--RENDERER_END-->" method="post" id="user-login-form" accept-charset="UTF-8">
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | renderviz2016-09-30_1044.png | 192.98 KB | itsekhmistro |
| #18 | Screen Shot 2016-09-27 at 13.37.46.png | 166.03 KB | wim leers |
| #14 | interdiff.txt | 1.48 KB | wim leers |
| #13 | 2640280-12.patch | 1.16 KB | wim leers |
Comments
Comment #2
claudiu.cristeaI guess because the action url is a placeholder?
Comment #3
claudiu.cristeaEDIT: accidentally duplicated.
Comment #4
wim leersIndeed.
Comment #5
wim leersComment #6
wim leersActually, the problem is broader: any non-HTML rendered output cannot be visualized by renderviz (at least not for now that's out of scope), because there's no HTML element to target that we can set a 3D transform, an outline or a box-shadow on. So, don't wrap any output that is not HTML (i.e. that is plain text) in renderviz metadata (which uses HTML comments).
Tested this approach on a page with a node comment form:
As you can see, only plain text has its wrapping renderviz metadata removed.
In fact, both before and after, we get
206 unique rendered elements on the page.— so thejquery.comments.jsjQuery Plugin wasn't even able to find those comments anyway in the first place!Comment #7
wim leersComment #8
wim leersI can confirm that this fixes all forms (e.g. comment form, module form, node form, star-to-add-or-remove-shortcut, et cetera).
Comment #9
itsekhmistro commentedHi Wim,
I have faced same issue with debug output and created a patch for it,
have contacted about it on your blog.
Please check the patch attached, it looks safer cause the patch in comment #6 will also exclude an output like "text ..." from debug.
What do you think?
Comment #10
wim leersInteresting :)
Why would excluding
text…be wrong? It's not HTML, so we wouldn't be able to safely wrap it. So it's behavior would be correct. The behavior of your patch is the same for that particular example.Can you give an example where your patch does the correct thing and mine (in #6) doesn't?
Comment #11
itsekhmistro commentedHi,
The ... dots in the example in comment #9 are a link.
"text <a>...</a>"I mean if the result output doesn't start with a tag but contains a tag/tags inside
- then we can consider that the output can be safely wrapped with debug info.
Comment #12
fabianx commentedRTBC for #9
Comment #13
wim leers+1. But I didn't think the comment was very clear.
Comment #14
wim leersThe interdiff was wrong.
Comment #15
wim leersAssigning credit.
Comment #17
wim leersUgh, I failed to squash the commits. My bad. But no big deal :)
Comment #18
wim leersIt looks like this caused a serious regression…
Comment #19
itsekhmistro commentedHi Wim,
Tested the latest version (with the patch applied).
Looks good as for me, please see the attached screenshot.
For the test I have used a fresh Drupal installation based the latest version of Drupal core (8.1.10).
Could you confirm that you 've got a regression ?