IAT seems to slow down this web page a lot (~30 seconds)

[dstndstn]

I'm a huge fan of It's All Text. However, it seems to cause a huge slowdown with a web site I use all the time: the "Query" page of the CasJobs database for the Sloan Digital Sky Survey:
http://skyservice.pha.jhu.edu/casjobs/SubmitJob.aspx
(unfortunately, this requires a (free) registration to login).

With IAT disabled, the page loads quickly. With IAT enabled, it seems to begin loading, then I get the dreaded Mac Happy Beachball of Death spinning for 20-30 seconds, and then the page finally loads.

I don't know what information I can provide to help tracking this down. (I also understand that this is a very obscure web site so fixing it is not going to be a priority!)

Sometimes I get the "Unresponsive script" dialog box, complaining about:
Script: chrome://itsalltext/content/cacheobj.js:206
or
Script: chrome://itsalltext/content/cacheobj.js:843
or other places.

Firefox 23.0
MacOS X 10.8.3
IAT 1.8.1

Here is a screenshot when I use the "profile" tool of the Firefox "Web Developer" tools.

Thanks for any help you can provide. I am also reporting this to the CasJobs team and will let you know if they have anything to say.
--dustin

[docwhat]

@dstndstn The profile screenshot you provided seems to imply an insane amount of mutation (changes to the web page) occurs. It's possible that there is even an infinite loop in there someplace (e.g. casjobs changes the page, IAT detects the change and makes a change, casjobs detects the change makes a change, etc.).

I'll see if I can create a test page to reproduce it when I have the chance.

[dstndstn]

Thanks for your response -- yes, sorry, I should have mentioned. The casjobs page pre-fills the TextArea with the last query you ran (because you often end up editing fairly complicated SQL queries there), so yes, I imagine it is some kind of update war.

[dstndstn]

Does this mean that IAT is monitoring the TextAreas even before the user hits the "edit" button to open an editor session? That is surprising.

I went digging a bit and it looks like the TextArea in question is a fairly complicate javascript dealie (it does syntax highlighting, bracket matching, etc); code is here:
http://skyservice.pha.jhu.edu/casjobs/scripts/codemirror.js

and the SubmitJob.aspx source is copied here:
https://gist.github.com/dstndstn/6213419

It looks like it does an update upon window resize (which maybe happens when the page loads?), which it does by saving the current query as "lastQry", and then calling "editor.setValue(lastQry)". That (in codemirror.js) seems to update each line in the query, which does a horrific amount of work and launches a "highlight" worker to do the syntax highlighting.

The funny thing is, after all that, the web page layout is such that the IAT "edit" button isn't even visible (and I would prefer to edit in my editor, of course)!

Please feel free to close this as "wontfix", or as a +1 of issue #34 .

Thanks again for IAT -- love it.

[docwhat]

I can probably throttle the updates to prevent the slow down. Let me see about getting you a test version when I can.

[docwhat]

@dstndstn Okay, try this version out: https://docwhat.org/files/itsalltext-1.8.1.1.xpi

I suspect it won't fix the problem, but if it does that'd be great.

[dstndstn]

I am very sorry for taking so long! Somehow just got busy and forgot that you had sent something to test.

I just tried and now I'm not getting the IAT "Edit" button in the bottom-right of (any) text fields. It is enabled in the preferences and I restarted firefox.

Any idea?

Thanks, and sorry again for the long delay.

PS, my Firefox version is now v24.0

[docwhat]

How's the performance?

Try accessing IAT via the context menu; right click on a text area.

[zao]

Any of the news pages for the League of Legends game exhibits similar hangs with 1.8.1.

The linked 1.8.1.1 mitigates the problem on those pages but as mentioned, the Edit button is now gone and you have to use the context menu to use IAT.

[noah]

I have experienced the same issue ... the ability to selectively disable IAT on certain pages might help. I.e., list of sites on which to blacklist IAT.

EDIT: I started hacking on a branch to implement domain blacklisting: noah@7b1de0c

@docwhat Where is a good place to check for whether document.domain is in the list??? This seems like it should only need a couple more LOC to work.

This might also fix #75. It's kind of a heavy-handed approach, but I'd rather have this simply give up on certain pages, than crash my browser session.

[docwhat]

@noah Cool!

So you can see checks for isHTML() and isXUL() in monitor.js.

You probably want to do something there like the !doc check at the top:

if (isBlacklisted()) {
  return [];
}

[noah]

I think I've got something working, feel free to give it a try:

noah@0e2d402

Somewhat difficult to debug FF addons so I'm not 100% sure.

Note: I placed the abort path in the isHTML function because it's not clear to me whether this should apply to editing .xul, but it could be moved trivially higher up in sequence.

Note: I force-rebased this commit into the one I linked to above.

[docwhat]

Did you look in the DEBUGGING.md file?

[noah]

Nope, but I managed to arrive at equivalent steps independently. Would have been helpful, though and bookmarked for future reference.