[Unrelated] ajax on dropbox.com

[dropbox]

Hi guys, running NoScript (also adblock plus, ghostery), and I've recently been having problems with dropbox.com. Previously, if I allowed dropbox, dropboxstatic and ajax.googleapis everything worked, but no longer. The symptoms are as if ajax is not loading - ie, no dynamic behavior in text boxes, and buttons don't work. Turning off all the plugins (noscript, adblock, ghostery) does not help - weird, right? Googling for this problem showed one stackoverflow question that did not get answered. I was wondering if anyone here has come across this problem? If not, could you instead suggest some directions to dig in, in order to debug this problem?

[Thrawn]

Well, for starters, if turning off NoScript didn't help, then it's not NoScript-related...but did you actually disable the extension, or just use Scripts Globally Allowed?

[barbaz]

(oops, Thrawn posted while I was posting. anyway...)

You realize you're asking the NoScript forum for NoScript support for an issue that's not related to NoScript right?
I'll still try to help you if you want though, because I do this stuff for fun. So anyway...

Try it in a new, clean profile. Does it work?

The symptoms are as if ajax is not loading

Test whether that's really the case: Use JSView to find out what scripts are trying to load from ajax (are they cached / can it determine the size?), then grab those scripts from some other CDN like maybe ajax.aspnetcdn.com (click the link I posted, don't try to go directly to the domain because that will just give you a not found page) and set them up as file: URL surrogate script, and see if it works (the surrogates should kick in if the real script doesn't load, but you can also try Forbidding ajax).

Set up each file: URL surrogate like so:
1) Download the script, save to your disk somewhere
2) Go to about:config in the browser
3) Create new string preference, name noscript.surrogate.ajax1.replacement, value is the file: URL pointing to the downloaded script
4) Create new string preference, name noscript.surrogate.ajax1.sources, value is a AddressMatcher patterm matching the URL of the script on the ajax server that isn't working. AddressMatcher is the same as ABE site syntax: ABE Rules .pdf

the 'ajax1' can be anything as long as it's the same in both prefs.

[dropbox]

Well, for starters, if turning off NoScript didn't help, then it's not NoScript-related...but did you actually disable the extension, or just use Scripts Globally Allowed?

I temporarily allow, which usually does the trick with such behavior (ajax not working). But yes, you're right - it's not necessarily NoScript. I'll try turning off the extension altogether.

(oops, Thrawn posted while I was posting. anyway...)

You realize you're asking the NoScript forum for NoScript support for an issue that's not related to NoScript right?
I'll still try to help you if you want though, because I do this stuff for fun. So anyway...

Try it in a new, clean profile. Does it work?

The symptoms are as if ajax is not loading

Test whether that's really the case: Use JSView to find out what scripts are trying to load from ajax (are they cached / can it determine the size?), then grab those scripts from some other CDN like maybe ajax.aspnetcdn.com (click the link I posted, don't try to go directly to the domain because that will just give you a not found page) and set them up as file: URL surrogate script, and see if it works (the surrogates should kick in if the real script doesn't load, but you can also try Forbidding ajax).

Set up each file: URL surrogate like so:
1) Download the script, save to your disk somewhere
2) Go to about:config in the browser
3) Create new string preference, name noscript.surrogate.ajax1.replacement, value is the file: URL pointing to the downloaded script
4) Create new string preference, name noscript.surrogate.ajax1.sources, value is a AddressMatcher patterm matching the URL of the script on the ajax server that isn't working. AddressMatcher is the same as ABE site syntax: ABE Rules .pdf

the 'ajax1' can be anything as long as it's the same in both prefs.

I didn't know where else to ask, that would be sympathetic to such problem
Thanks for the detailed writeup. The file url would look like this, correct?

Code: Select all

file://C:\whatever\whatever.js

Also, for this surrogate to work, I don't have to enable the original "offending" resource, correct?

[barbaz]

I didn't know where else to ask, that would be sympathetic to such problem

Heh.

Thanks for the detailed writeup. The file url would look like this, correct?

Isn't it

Code: Select all

file:///C:/whatever/whatever.js

?

I don't use Windows so I don't know. You can get it exactly by opening the JS file in your browser.

Also, for this surrogate to work, I don't have to enable the original "offending" resource, correct?

Correct.

[dropbox]

Thank you for the clarification barbaz. I was able to get ajax running from a locally cached copy. Turned out it wasn't the cause of the problem, however. I tracked down the real culprit to `dom.indexedDB.enabled`. Somehow, if indexedDB is turned off, some of the js is unable to run.

How does this work? Is this something specific to dropbox's code?
What is the best way of dealing with `indexedDB`?
Just leave it on? But doesn't that lead to the possibility of tracking?

[barbaz]

Leave IndexedDB enabled. Otherwise yeah sites that depend on it will break.
You can figure out exactly what's breaking by looking at messages in the Browser Console (Ctrl-Shift-J) when you have IndexedDB disabled. Depending what it is maybe you can get away with IndexedDB disabled and a surrogate script containing dummy stubs of IndexedDB APIs.

If you enable IndexedDB, and if you don't want to be tracked via IndexedDB stored data, when Firefox is not running you can probably go to the profile folder, and go to the storage folder in there and delete site data you don't want to keep.
(I don't think I've deleted IndexedDB data that way ever so I don't know the consequences, so completely quit Firefox and backup the entire profile folder first! Well, OK, so I might have purged IndexedDB data in a test environment once out of curiosity and forgot both exactly what I deleted and the results . Whatever.. In any case a backup won't hurt.)