Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graph info panel is broken #3557

Closed
stephanwlee opened this issue Apr 28, 2020 · 1 comment · Fixed by #3582 or #3723
Closed

Graph info panel is broken #3557

stephanwlee opened this issue Apr 28, 2020 · 1 comment · Fixed by #3582 or #3723

Comments

@stephanwlee
Copy link
Contributor

stephanwlee commented Apr 28, 2020

Symptom: after the #3476 refactor, the graph info panel is broken.

Cause:
After the change, the iron-list dom-module is missing from the document. When inspecting the elements more carefully, it appears like following:

    <div id="numeric-alerts-table-container">
          <table id="numeric-alerts-table">
            <thead>
              <tr>
                <th>First Offense</th>
                <th>Tensor (Device)</th>
                <th id="event-counts-th">Event Counts</th>
              </tr>
            </thead>
            <tbody id="numeric-alerts-body"></tbody>
          </table>
        </div>
      </div>
      <template is="dom-if" if="[[!_hasDebuggerNumericAlerts(debuggerNumericAlerts)]]">
        <p class="no-numeric-alerts-notification">
          No numeric alerts so far. That is likely good. Alerts indicate the
          presence of NaN or (+/-) Infinity values, which may be concerning.

<dom-module id="iron-list">
  <template>
    <style>

As you can notice, the DOM is quite broken. There are multiple closing tags from tf-graph-debugger-data-card are missing.

Upon more careful debugging, I have found out that the Vulcanization is actually responsible for such structure.

For instance, <p>foo</p> gets compiled into <p>foo. Similarly,

<template>
  <p>foo</p>
</template>
<dom-module id="iron-list">
</dom-module

<!-- gets compiled to -->
<template>
  <p>foo
</template>

<dom-module id="iron-list">
</dom-module

When debugged further, I found that there are some heuristic on HTML5Printer of jsoup that we use which omits closing tag of certain tags when they are the last one in current level https://github.com/bazelbuild/rules_closure/blob/d1c0bb4862882e0444ee478aa2091d41a4df084e/java/org/jsoup/nodes/Html5Printer.java#L209-L214.

I think the intention was good but if you parse then print below code using jsoup, you get quite wrong code.

<div>
  <p>foo
</div>

<!-- converts to -->
<div>
  <p>foo

There are three ways to move forward:

  1. fix jsoup not to wrongfully remove closing tag of parent node
  2. never do multiple passes of jsoup parse and print
  3. use genrule to inline polymer_lib into tensorboard.html since inlining is all we need.

cc @bmd3k

@stephanwlee
Copy link
Contributor Author

I think I understand the issue better now, @bmd3k.

When we are iterating and flattening HTML, we put the document in place of the link elements: https://github.com/tensorflow/tensorboard/blob/master/tensorboard/java/org/tensorflow/tensorboard/vulcanize/Vulcanize.java#L324

This results in a document like:

<html>
  <head>
    <document>
       <head>
        ...
    </document>
  </head>
</html>

Of course, <document> is non-sensical. Our printer, basically knows to ignore these elements (https://github.com/bazelbuild/rules_closure/blob/d1c0bb4862882e0444ee478aa2091d41a4df084e/java/org/jsoup/nodes/Html5Printer.java#L121-L123) but the default serialization does not. As a result, you see HTML stringified with awkward <#root> elements throughout.

I tried to see if we can not replace with the document but replace the link element with <head> and <body>. Sadly, our webpath logic strongly depends on the document being injected:

if (node instanceof Document) {
stack.remove(stack.size() - 1);

Ideas that I have right now is a post-process step on the resulting document to remove all the intermediate documents before writing it out since we cannot pass our own traverser onto the printer (https://github.com/jhy/jsoup/blob/89580cc3d25d0d89ac1f46b349e5cd315883dc79/src/main/java/org/jsoup/nodes/Node.java#L606)

stephanwlee added a commit to stephanwlee/tensorboard that referenced this issue May 6, 2020
The issue is better described in tensorflow#3557. Please refer to it.

Our HTML module traversal relies on the `document` so we cannot create
the document without nested document in one go. Instead, we do a post
processing of the document to prune away all the `document` so the
default jsoup's printer can print them without awkward `<#root>`
elements.

index.html size difference:
```
555323 before
554749 after
```
stephanwlee added a commit that referenced this issue May 7, 2020
The issue is better described in #3557. Please refer to it.

Our HTML module traversal relies on the document so we cannot create
the document without nested document in one go. Instead, we do a post
processing of the document to prune away all the document so the
default jsoup's printer can print them without awkward <#root>
elements.
caisq pushed a commit to caisq/tensorboard that referenced this issue May 19, 2020
The issue is better described in tensorflow#3557. Please refer to it.

Our HTML module traversal relies on the document so we cannot create
the document without nested document in one go. Instead, we do a post
processing of the document to prune away all the document so the
default jsoup's printer can print them without awkward <#root>
elements.
caisq pushed a commit that referenced this issue May 27, 2020
The issue is better described in #3557. Please refer to it.

Our HTML module traversal relies on the document so we cannot create
the document without nested document in one go. Instead, we do a post
processing of the document to prune away all the document so the
default jsoup's printer can print them without awkward <#root>
elements.
caisq added a commit that referenced this issue Jun 10, 2020
… link importing (#3723)

* Motivation for features / changes
  * Roll forward #3582 with change, in order to fix #3557.
* The solution is primarily due to @stephanwlee. When such midway imports are found,
   a `RuntimeException` is thrown with an error message describing the cause and the
   offending element.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment