[credit to dshin for noticing this bug; I just reduced the testcase a bit from bug 1800897, where he originally noticed it when poking at the more-complicated external URL over there]

STR:

1. Load attached testcase (just an iframe pointing at a Google Calendar embed)
2. Select some text (e.g. click before "Thu" and drag over to "Sat" to select those words)
3. Right-click near that selected text and choose "Print Selection"

ACTUAL RESULTS:

• First, a Print Preview error dialog appears ("There was an unexpected problem while printing")
• When you click "OK" on that dialog, an actual print/print-preview dialog appears, which says "Preparing Preview..." with a throbber that never finishes loading.
• If I click "Print" on that dialog (ignoring the fact that the preview never loads), with the Save to PDF printer, then Firefox acts like it's saving a PDF, but none is actually generated.

EXPECTED RESULTS:

• Obviously no-errors-at-all is the best case scenario.
• But when we do hit an "unexpected problem" as we do here, ideally we shouldn't still show a print-preview dialog.
• If we do show a print-preview dialog but fail to produce printed output when the user clicks "print", ideally we should alert the user to this fact instead of silently failing.

I can print-selection just fine if I only select the title-text December 2022, or the "Google Calendar" logo at the bottom-right (the word "Calendar" there is real selectable text).

It's only the dates in the middle that are problematic. Those are in a table, so this might have something to do with table selection ranges being fiddly, as noted in bug 1694417 comment 10.

Ah no, it's not table-specific. It's just that part of the subtree gets nuked on printing, and that part is reinitialized via a innerHTML assignment.

You can see this if you look for the element with id="viewContainer1" and place a breakpoint on subtree modification. When you print-selection, that breakpoint fires in a deeply-nested call-stack inside of a resize event handler, with the breakpoint being paused on the innerHTML assignment here:

    Nb = function (a, b) {
      if (Zg()) for (; a.lastChild; ) a.removeChild(a.lastChild);
      a.innerHTML = Wg(b)
    };

https://calendar.google.com/calendar/_/web/calendar-static/_/js/k=calendar-web.embed.en.G3xfjUOrvso.es5.O/d=1/rs=ABFko39u1VsbKdbQGZ2mnv95FTfmCoRoag/m=embed

Here, a is viewContainer1.

So it seems that our print-selection operation is causing a resize event to fire (for some viewport, either the top-level one or the iframe's viewport, being resized to fit the print viewport); and that triggers a resize event handler to fire; and that triggers some JS which replaces a bunch of the DOM, including the portion that the selection happens to live in.

So we end up with an empty (or no-longer-in-the-DOM) selection range, by the time we're ready to actually render.

Seems to boil down to resize event modifying the DOM, regardless of iframe (Which makes sense).

There's something more subtle here, I think. At least: Chrome seems to differentiate between David's reduced testcase and the original google-calendar testcase.

With David's reduced testcase, Chrome gives similar "oh well" results to Firefox (without the error message): If I select "Hello" and then open the print dialog in Chrome, the selection gets entirely lost in the original page; and if I print-selection (by checking the "Selection" textbox in their print dialog More Settings), then the print preview is just blank.

But with the original Google Calendar "testcase 1" (attachment 9309476 [details]), Chrome seems to Just Work with printing and selections. I can select some text (e.g. day-names or day numbers in the calendar), and that selection is preserved if I open the print dialog with Ctrl+P; and the selection shows up properly in print preview if I check the "Selection" textbox.

So Chrome's doing something graceful that makes this work. In the gcal example, maybe the DOM isn't getting fully destroyed with an innerHTML assignment, but instead a subtree is just moving around, and their selection ranges are more robust against that sort of mutation?