WorkFlow Macro displays "Enable JavaScript to display the workflow graph."

[Ryan J Ollos]

To reproduce:

• Go to ticket #7871.
• Add the text comment:10 to Add a comment.
• Wait for auto-preview to generate a preview.
• Observe that Enable JavaScript to display the workflow graph. is displayed in comment:10.

Observed on t.e.o with Windows 7 and Firefox 12.0.

[Remy Blank]

That's because we render the workflow graph only once at page render time. We currently don't have a mechanism to call processor- or macro-provided JavaScript at preview time. The same will probably happen in the automatic wiki preview.

[Ryan J Ollos <ryano@…>]

Replying to rblank:

That's because we render the workflow graph only once at page render time. We currently don't have a mechanism to call processor- or macro-provided JavaScript at preview time. The same will probably happen in the automatic wiki preview.

I've also noticed in 0.12.3 that pygments syntax highlighting is not present when auto-previewing a ticket comment. Syntax highlighting is present after one explicitly invokes a preview. Is that possibly for the same reason? (although I thought Pygments was a pure-Python package, so maybe not …)

[Remy Blank]

It's not exactly the same reason, but it's related. Syntax highlighting processors provide the CSS to be used after page rendering has already begun, so we can't add it as a <link> in the page header. Instead, it's loaded with JavaScript at the end of rendering. If you happen to already have a syntax highlighting processor on the ticket when you start adding a comment, rendering works fine, because the CSS is already loaded. Try adding a comment with a {{{#!python}}} block to e.g. #10644 if you want to see it in action.

[Jun Omae]

Replying to Ryan J Ollos <ryano@…>:

I've also noticed in 0.12.3 that pygments syntax highlighting is not present when auto-previewing a ticket comment.

This issue has been reported as #10470.

[framay <franz.mayer@…>]

When using Workflow macro in Wiki page, it always displays message Enable JavaScript to display the workflow graph. See ​demo-0.13/SandBoxWorkflowTest.

Tested with Firefox 12.0, Chrome 18.0 and IE 9.0 (all under Win7).

[Christian Boos]

Replying to framay <franz.mayer@…>:

When using Workflow macro in Wiki page, it always displays message Enable JavaScript to display the workflow graph. See ​demo-0.13/SandBoxWorkflowTest.

Tested with Firefox 12.0, Chrome 18.0 and IE 9.0 (all under Win7).

Thanks for the report, but that problem was already fixed in r11033 and the 0.13-demo site was not yet updated.

[Jun Omae]

Proof of concept can be found in jomae.git@t10674_1.0. After the patch, script data and script elements which are added by macros while rendering wiki append to response of XMLHttpResponse.

[Jun Omae]

Updated jomae.git@t10674_1.0, targeting 1.0.3. Rather, should we retarget 1.1.3? Also, could someone please review it?

[Ryan J Ollos]

The changes work well for me. I'll look at the code more closely tomorrow. I think it's good to target to 1.0.3 since it's a pretty significant defect in Trac. I can't see how it would negatively affect any plugins, do you? (On the other hand I'm reconsidering for some of the changes I've pushed to #11813 recently, which probably should have been targeted to the trunk because they are aesthetic issues only, and changing the structure of the page can negatively affect plugins).

[Christian Boos]

Reviewing:

• for [95943ba069/jomae.git] commit message, it feels like "prevent reflow by rendering workflow graph" is wrongly worded:
  • either "prevent reflow when rendering workflow graph"
  • or "prevent reflow by pre-setting placeholder size before rendering workflow graph"
• for the change itself, it works but on Firefox I see that the system-message box is visible for quite some time before it gets replaced with the workflow graph; looking again, it's also there flickering in Chrome. I thought about adding a visibility:hidden rule on it with Javascript? → log:cboos.git@review/t10674_1.0
  With that the "red box" flicker is no longer there, but it seems that Firefox collapses the space allocated to the box even though I think it shouldn't. The only browser in which this seems to work flawlessly is IE, probably not a good sign ;-) Maybe you can improve upon my experiment?
• for [732cc77619/jomae.git], looks good! (nitpick for the commit message, "make … macro work on auto-preview")

[Jun Omae]

Thanks for the review! Reviewed commit messages will be used when I'll push the changes.

Another solution for the red box flicker can be found in [3adeb8dd/jomae.git]. noscript element is used in the changes.

[Christian Boos]

Replying to jomae:

Another solution for the red box flicker can be found in [3adeb8dd/jomae.git]. noscript element is used in the changes.

Yes, nicer solution than mine! The red flicker is completely gone, but there's still some collapse/expand that can be seen with FF (33.1) and Chrome (38.0.2125.111). Only IE 11 seems able to avoid the reflow.

[Jun Omae]

Replying to cboos:

Replying to jomae:

Another solution for the red box flicker can be found in [3adeb8dd/jomae.git]. noscript element is used in the changes.

Yes, nicer solution than mine! The red flicker is completely gone, but there's still some collapse/expand that can be seen with FF (33.1) and Chrome (38.0.2125.111). Only IE 11 seems able to avoid the reflow.

Hmm, I cannot still reproduce the collapse/expand problems.

Also, functional tests fail with that changes. XHTML1 strict DTD disallows the noscript element in head element. I'll rework it.

[Jun Omae]

Updated jomae.git@t10674_1.0. Could you please try it?

[Christian Boos]

overlap issue with [b885614b03d3/jomae.git]

[Christian Boos]

Replying to jomae:

Updated jomae.git@t10674_1.0. Could you please try it?

Nearly there! The collapse/expand issue is indeed gone (in FF, Chrome, still fine in IE) but there's now another glitch: in those 3 browsers, there's an unfortunate interaction when a float is around, like in the TracWorkflow page:

Looking for ways to prevent it, so far no luck except for a { display: inline !important } or (inline-block) which only works in FF and doesn't sound right anyway…

[Christian Boos]

Replying to cboos:

Looking for ways to prevent it, so far no luck…

Ok, with this it seems to work:

trac/htdocs/js/workflow_graph.js

@@ -223 +223 @@
                     source: nodes[sourceindex], target: nodes[targetindex]});
       }
 
-      var canvas = $('<canvas>').css({width: width, height: height})[0];
+      var canvas = $('<canvas>').css({width: width, height: height,
+                                      display: 'block'})[0];
       canvas.width = $(canvas).width();
       canvas.height = $(canvas).height();
       if (typeof(G_vmlCanvasManager) != 'undefined')

trac/ticket/default_workflow.py

@@ -500 +500 @@
         return tag(
             tag.div('', class_='trac-workflow-graph trac-noscript',
                     id='trac-workflow-graph-%s' % graph_id,
-                    style="height:%spx" % height),
+                    style="display:inline-block;height:%spx" % height),
             tag.noscript(
                 tag.div(_("Enable JavaScript to display the workflow graph."),
                         class_='system-message')))

(inline would also do, but inline-block sounds better as we're dealing with a div…)

[Jun Omae]

I just created patch similar to that, [bcf71c284/jomae.git]. The canvas element is defined as ​block element, but browsers practically render as inline-block.

[Christian Boos]

Replying to jomae:

I just created patch similar to that, [bcf71c284/jomae.git].

Flawless behavior in all the browsers tested (FF, Chrome, IE on Windows). Great job!

[Jun Omae]

Okay. Thanks for your reviewing and testing! I'm going to push the changes and close #10674,​10470.

[Jun Omae]

Pushed in [13330-13331] and merged to trunk in [13332].