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

[Chrissy Safranski]

Using CLI 2.44 (upgraded today), if I use the dev version of doenet inside pretext, I get issues with none of the math loading.  Almost everything in an m-tag isn't visible at all; one or two things showed unrendered LaTeX.  

If I use the standard version of doenet, commenting out the `<doenetml version="dev" />` from my docinfo, the math seems to load just fine. (But I've used dev features in some problems, so that's an issue, too.) 

Chrissy

[Duane Nykamp]

Oh no. I've made a lot of improvements with the dev version, including fixing the MathJax loading problem referenced below. I was about to make an official release with the improvements, but I guess that would break math with the new CLI.

What changed with the CLI that would break what I changed? I prevented DoenetML's MathJax from clobbering a host MathJax, as promised. I also made some other changes to prevent raw Latex from flashing with dynamic math.

I'll look into this, but any pointers into what changed would be helpful!

Duane

You received this message because you are subscribed to a topic in the Google Groups "PreTeXt development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pretext-dev/JAmt-9qhXuI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/f9211459-9222-458d-851c-9567746bb3b9n%40googlegroups.com.

--

Duane Nykamp
School of Mathematics
University of Minnesota
202 Vincent Hall
206 Church St. SE
Minneapolis, MN 55455
www.math.umn.edu/~nykamp

[Oscar Levin]

I can't think of anything that has changed in the CLI recently except using a more recent version of the core pretext libraries.  Those now use the recent upgrade of mathjax... But probably looking at the commits on pretext is your best bet for finding the issue.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CANX2AUZDGD6bOpwYSWrdVfEoF_Ke_ecX8kw9nqSYd%2BY4ziFiPA%40mail.gmail.com.

[Chrissy Safranski]

I saw the same problem with no math loading using 2.43.1.  I've just been trained that when I see unexpected behavior, one of the first things I try is updating PreTeXt. :-)

I downgraded to 2.33.0 (chosen because I knew I had used that successfully before) and the math loads fine using the doenet dev version.   So something between there!

Chrissy

[Duane Nykamp]

I released a new dev version of DoenetML that fixes the issue. 

If  `<doenetml version="dev" />` still causes issues, you could temporarily change it to `<doenetml version="0.7.20-dev.339" />` to force the updated version.

Assuming this works OK, my plan is to release a new version 0.7.21 today that will include all these fixes for those who do not specify a doenetml version.

Duane

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/7b3a7a35-0d0a-4afe-892b-29a0853d8d4an%40googlegroups.com.

[Chrissy Safranski]

Setting the version specifically using  `<doenetml version="0.7.20-dev.339" />` worked!  I see numbers and expressions in Doenet again with CLI 2.44.0.

Thank you!

Chrissy

[Duane Nykamp]

Version 0.7.21 of DoenetML is out. (It's essentially equivalent to 0.7.20-dev.339.) If you don't specify the DoenetML version, then you should get that new version.