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).

  • 1
    Well, mostly. I think this proposition has some merit.
    – Tim Stone
    Commented Jul 19, 2014 at 3:31
  • @TimStone I don't know if this is actually a duplicate. My other post (the bug report) certainly was, but those posts were "what is happening?" while this one is specifically "maybe we can fix it this way" (I made this just to keep the feature request separate from the "what is the cause?").
    – Jason C
    Commented Jul 19, 2014 at 3:48
  • 1
    Yeah, it's a little weird because the correct response to the bug report would have been to fix it (it's certainly not intentionally terrible), in which case you wouldn't have had to have a separate feature request...but meh.
    – Tim Stone
    Commented Jul 19, 2014 at 4:02
    – Jason C
    Commented Jul 19, 2014 at 4:04
  • I think he's new here. ;)
    – Tim Stone
    Commented Jul 19, 2014 at 4:05
  • 1
    @TimStone no it's not duplicate. It's suggesting a totally different thing. Commented Jul 19, 2014 at 7:41
  • @ShadowWizard meta.stackexchange.com/a/194495/165773
    – gnat
    Commented Aug 1, 2014 at 20:50
  • 1
    Just as a heads up, I'm going to tackle this after I take care of updating some authentication pieces (which I'm a bit behind on, whoops...)
    – Tim Stone
    Commented Aug 4, 2014 at 18:45
  • 1
    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.
    – Louis
    Commented Oct 23, 2014 at 12:41
  • The fundamental issue seems resolved now, as the plots are in a separate tab and no longer rendered immediately on page load. Cool beans.
    – Jason C
    Commented Mar 9, 2015 at 9:29

1 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.

  • 1
    I would turn it off by default and let people turn it on once they are confident they have a good query. It is too easy as one works on a query to end up with something that will cause the plotting software to freeze the browser.
    – Louis
    Commented Oct 23, 2014 at 12:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .