Ability to disable SEDE plot for a query link, before the query is run

Question

The Problem

This request is to address Data Explorer page keeps freezing Chrome and Firefox.

There is an issue now where large queries that result in complex plots can bring the browser to a grinding halt when plotting the query, thus leaving the query unviewable and uneditable - even for queries where plots are not appropriate or desired.

For example (may freeze your browser), this query that I was recently working on. For me it freezes Firefox and Chrome (on Linux), and there was a confirmation of the issue for IE11 as well.

Pulling relevant conversation from the bug report comments and (hopefully accurately) trimming it down, the reason is given as:

Haney: The problem appears to be the complexity of the Flot JS work. I get told that the script has become unresponsive. Additionally, the graph has a lot of vectors/drawings on it. The query involves > 22,500,000 results, so it makes sense that it's overloading the browser.

My argument is as follows:

Jason C: As the originator of said query ... I didn't want the plot in the first place, it's not really a plot-able query, but now I'm locked out of editing it because the inappropriate plot that I do not (and will not) want is blocking the page ... I can't continue work on that query without copying + pasting it into a new one (which currently I can only do on Chrome by clicking inspect in the window before it freezes ... ).

A counter-point is:

Haney: I mean I could have a do not plot checkbox but it isn't really going to help you avoid clicking on the query originally and getting JS-bombed. I feel like this is a one off and the originator of the post should exercise caution in creating crazy plots. Another option is to make plotting default to off and have to select it, but I feel like that would upset at least a good portion of the SEDE users. ... I feel like the community would need to discuss it and come to a consensus as it'd be a fairly decent change to SEDE.

Uncommon case or not, I believe there is a need to prevent being locked out of a query by a stuck plot, especially if the plot is not desired, and especially if the end result is a browser crash or hang.

---

Current Workarounds

There are no reliable workarounds that I know of other than attempting to catch the query text in the browser in the few seconds before the page stops responding and paste it into a new query (but this does not help permalinks, only query editing).

There is one workaround that should work in theory but does not: Adding the opt.textResults=true URL parameter should cause the query to execute text-only and not create the plot. However, while this parameter causes the "text-only" box to be checked, it does not display the results in text-only mode (in fact, from my end, I have not been able to make this work yet).

There is a workaround that can be done during editing / development of the query, which is to always run text-only results. However, this only applies during editing and does not help for permalinks as described above.

An additional workaround is described by Louis in a comment below:

Louis: An additional workaround to grab the text of a query that has bombed is to use wget or curl (or whatever equivalent you have) to grab the HTML of the page. Unfortunately, quotes will be encoded with HTML entities. However, I found myself unable to grab the text off of the page in the browser because the whole thing freezes on me before I can do anything.

In any case all workarounds involving text-only mode are undesirable as they disable hyperlinks in magic columns such as [Post Link].

---

The Point

I would like to discuss possible solutions, with the goal of never allowing a plot-related browser hang to lock one out of viewing / editing a query while at the same time keeping smooth UX for people who want the plot enabled by default (which Haney's comments indicate to me is a majority).

Many times a plot is not desired or appropriate, and I believe it is especially stinky UX when a plot blocks the page from loading when it is not desired to begin with.

In my opinion the issue has to be resolved (edge case or not) because the side effects block access to a portion of the site, and may not always even be expected (e.g. if a mistake is made in a query that causes it to be large, or if, in my case, it is an intermediate form of the final desired query being developed).

Answer 1

My proposed solution is as follows (all three):

• Add a "do not plot" check box to the UI, unchecked by default (plot on by default).
• Add a corresponding boolean URL parameter (e.g. opt.doNotPlot) that is always honored.
• Ensure that the URL parameter is present in permalinks.

I believe this is a good compromise in that it does not change the default behavior and, while not guaranteeing that the issue does not happen, gives a fallback plan to regain control of the query by allowing addition of opt.doNotPlot=true to the URL of a broken query.

By having the URL parameter always be honored, and ensuring it is present in a permalink, the originator of the query now also has the power to judge whether or not a plot is appropriate / possible when sharing the link, so that other unsuspecting users are not doomed to a browser hang when clicking the link.

Ideally the URL parameter would also be present in query browsing lists (i.e. on the DE main page) but I do not know enough about the internal workings of the system to even guess if that is a big change or not, and at least the ability to prevent the problem from happening after it is observed on a case-by-case basis is a workable fix.