13

On post revisions that don't change the post's rendered output, such as addition/removal/edits of HTML comments, changing inline links to footnote links, changing image descriptions, etc., the toggle to change to or from the Side-by-side Markdown view doesn't work properly.

Some facts for context:

  • When a revision history page is loaded, the type of diff view that gets shown depends on what type the user selected when they last loaded a revision history page, or Inline if they never made a choice. Using the toggle to change the type (normally) will also save the selection server-side so future history loads load with that type.
  • Edits that don't make a change to a post's rendered output show up as blank revisions in the Inline and Side-by-side [rendered output] views.

With those out of the way, let me describe the exact behavior:

  • If the post's pre-loaded diff view type is Side-by-side Markdown, the edit properly shows up. When changing from that to Inline or Side-by-side, the diff view fails to load - it gets stuck with a loading circle within each button. However, the user's selection is saved server-side, and refreshing the page will show the diff in the view that the user selected. (This only applies to the user's first selection - if the user, say, selected Side-by-side, then after seeing the loading circle selected Inline, then on the next page load it will show as Side-by-side.)
  • If the post's pre-loaded diff view is Inline or Side-by-side, attempting to change to Side-by-side Markdown outright fails with no loading screen. The user's selection is not saved server-side, and in order to view the Markdown change it is necessary to change the server-side selection another way (through a different revision of the same post or another post's history page entirely), then refresh the page.

As Makyen commented, in the first case, this is due to the server not returning the required data, which causes SE's code to get into an infinite loop requesting data from the server, which causes excessive load and may lead to IP blocks.

In both cases, I checked for errors in the JS console, but there weren't any.

For some reproducible cases, see revisions 5 of this post and this post.

Can this please be fixed to work properly? I think it's getting confused with the blank rendered output diffs.

Improve this question
5
  • 6
    This is, actually, quite bad. SE's code enters an infinite loop and repeatedly makes AJAX requests trying to get the actual diff data from /revisions/<postID>/<revision UUID>/diff?difftype=<diffType>&full=false. How many times per second the request will be made depends on SE's backend and the round-trip delay from the requestor, but it's probably going to be in the range of 4 or 5 times per second. The page will need to be reloaded in order to break the infinite loop. The infinite, rapid requests might contribute to an IP rate limit ban.
    – Makyen
    Sep 15 at 20:17
  • 4
    This happens, because there's no .js-diff-panel[data-url=""] in the AJAX response, so nothing is replaced in the page (in loadDiffPanels()) and the code in the click handler added in bindDiffTabs() unconditionally fires off another .click() event on the newly selected tab without checking to see if the loading of new content in the DOM was successful and won't infinitely repeat. The code assumes that what it gets as a response form the backend is either sufficiently valid to trigger replacement, in a manner that won't cause a loop, or that the AJAX call will result in an error.
    – Makyen
    Sep 15 at 20:18
  • @Makyen The behavior you described takes place in which of my bullets outlining the bug? The first one? If so, what happens for the other?
    – Sonic the Anonymous Hedgehog
    Sep 15 at 20:51
  • 2
    For these, it's when you click to change to a different view. It gets "stuck with a loading circle", which is when SE's code is making AJAX requests for the same resource, getting a response, but not actually making a change, and then repeating that a few/several times per second.
    – Makyen
    Sep 15 at 20:56
  • @Makyen Thanks. What exactly happens when the page is pre-loaded with one of the two rendered output views and the user attempts to change to Markdown view? I believe it's a client-side error based on the lack of a loading circle and that the server doesn't save the preference, but I don't see any errors in the console.
    – Sonic the Anonymous Hedgehog
    Sep 15 at 21:35

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .