Doenet activities inside PreTeXt book pages

[Mitch Keller]

We are experiencing issues with the loading of Doenet activities in Active Calculus Single Variable. So far, the issue appears to only manifest in Chrome; Safari and Firefox are fine. Some sections of ACS load fine, such as Section 2.2: The sine and cosine functions. However, Section 4.2: Riemann sums (as an example) gives the Doenet logo in the Preview Activity area at page load but then resizes as if there is no content. None of the Doenet activities on that page load as embedded. However, if you click the icon to open in a new window, the Doenet activity standalone page is fine.

Oscar and I looked at this a bit at drop-in today, and there is speculation that this may be some sort of Javascript timeout issue that may be related to the number and/or complexity of the Doenet activities in a page. However, we weren’t able to confirm anything.

Any thoughts folks have that could track down the source of the problem (and a fix) would be appreciated!

Thanks,

Mitch

-- 
Mitch Keller
mi...@rellek.net

http://www.rellek.net/

[Andrew Scholer]

FWIW -

I can't reproduce a full failure to load. I do get the Doenet logo in each area, then they resize to nothing but a narrow white box, but then if I keep waiting, they eventually do populate. But it does take about 15 seconds to load that page fully.

There are a number of big performance issues:

- Chrome's performance monitor tells me that doesnet-standalone.js is 29MB. It is loaded into each iframe. Even when it comes from the cache, the browser reprocesses that bundle in each iframe. 

- There is a lot of blocking logic in the load for each of those iframes.

- The rendering of math causes a lot of layout thrashing.

Some combination of splitting up the doenet-standalone.js (possibly lazy loading some parts), adjusting the mathjax processing, and avoiding blocking during load events triggered by doenet would help get content up faster.

Or you could go the Sage route and activate on demand.

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/DED06275-68A5-4BA7-8E54-F4771CFA3B6E%40rellek.net.

[Mitch Keller]

Thanks, Andrew. Even after more than a minute of waiting, I still don’t get any of them to load in my 4.2 example page. I get the Doenet logo screen like you describe, but then it doesn’t do anything further.

Hopefully @Duane can chime in on what performance improvements from your list would be feasible for him to implement. What PreTeXt produces is an HTML file that goes into an iframe. That HTML file contains script/type=“text/doenetml” that appears to get handled by the Doenet JS.

While WeBWorK (not Sage) does have the activate button currently, that’s facilitated by having static versions shown by default. I know static versions of Doenet activities is a bigger thing to deal with, but if Duane can’t streamline the loading issues upstream, then maybe no static preview with an activate button would be better than nothing loading at all for some users.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N8y7Ln_%2B9iAv-WefT17rFcjt6X65%2B-BbJB5DzJovB4iYg%40mail.gmail.com.

[Matt Boelkins]

I'm getting the same behavior occasionally, and it seems kind of random.  This morning I deployed recent work and was seeing it in section 5.2; I navigated to some other sections where I didn't see it, and then later tried 5.2 and everything was fine.  When the issue arises, this is what I see:

https://www.dropbox.com/scl/fi/5zr2jdhz7m8x034kjxlc3/doenet-loading-issue.jpg?rlkey=bcxcefz6htz6kix39wqmuv127&dl=0

Here's a link to the live location in the textbook where I'm currently seeing the behavior: https://mattboelkins.github.io/active-calculus-single-mbx/doenet/sec-5-4-parts.html#ez-5-4-doenet-2

Matt

[Andrew Scholer]

It looks like there are conflicting versions of mathjax being loaded with different patterns.

PreTeXt generates:
<script defer="" src="https://cdn.jsdelivr.net/npm/mathjax@4/tex-mml-chtml.js"></script>
along with some startup logic to load various packages.

Something (presumably Doenet) injects this into the <head> after the previous line:
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/mat...@4.1.0/tex-mml-chtml.js"></script>

Notice the different version and the fact that this is not loaded with "defer".

Those are the ingredients for the race condition. I don't know what the best solution is.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/f6a042c2-1398-4b83-a2ef-2135b8a7dac8n%40googlegroups.com.

[Duane Nykamp]

I agree with this analysis. Thanks for digging into this!

The Doenet viewer's MathJax wrapper unconditionally injects its own pinned mat...@4.1.0 script and assigns window.MathJax on the way — so when PreTeXt's deferred MathJax script has already initialized, the live engine object gets overwritten with a config object, and whichever script wins the race determines whether the page renders. That's why it's intermittent and looks browser-specific (it's load-order timing, not Chrome).

MathJax 4.1.3 was published July 3 — so every published book changed MathJax versions days before these reports. That could explain the timing.

The "resizes to nothing" is a second bug: the Doenet viewer starts reporting its content height to the parent as soon as it mounts — including near-zero heights while it's still booting or when the render has died — and PreTeXt obligingly collapses the iframe. We'll fix that on the Doenet side (to not send resize events until first real render).

We'll also fix Doenet so that it can coexist with a host-loaded MathJax instead of injecting a second one.

In the meantime, if PreTeXt wants to remove the bug immediately, you could drop PreTeXt's MathJax <script> from the Doenet -if.html pages — this removes the race with Doenet's MathJax entirely.

Also, PreTeXt could add loading="lazy" to the interactive iframes. Each Doenet iframe currently parses a ~29 MB bundle and boots a worker at page open; on pages with several activities that pile-up will make things slow down.

Longer term I think Mitch's activate-on-click idea may be the right default for embedded activities. Doenet is close to having a static version that is vanilla PreTeXt. We could have that show until the activate button is clicked.

We also have work on the Doenet side to reduce the memory footprint.

Duane