Or, simpler and more efficient:

beforeSelectRow:

Hi Tony,

Thanks. Im going to be away for the w/e so wont be able to look at it until Monday.

One more thought… Math.round may be the answer after all.

The current formula is supposed to take a pixel value, and return the page that contains that pixel. For that, Math.round would be wrong (if you were in the lower half of the page, it would give the /next/ page).

But in this case, if all the calculations are correct, the pixel should always be the /first/ pixel on the page. But Im guessing (from Kaleb's investigation) that something isnt quite adding up, and we're getting an off by 1 (or perhaps off by border, or margin, or padding width, or some such) error. So Math.round ought to give the correct result.

Somehow doesnt feel right, because its just hiding the fact that the calculation isnt quite correct… but I think it /should/ work, as long as the error is less than half a page :-\

For the cells with images case… if the rows aren't all exactly the same height (?), the scrolling rows feature just isnt going to work as it stands (it depends on being able to translate back and forth between pixel offsets and row numbers /without/ having looked at all the preceding rows). I think it may be possible to fix that, but would require changing the scrolling logic somewhat…

Mark

It's still odd that visiting the page /advertisers loads correctly, just not the AJAX (JSON) request to the same URL. Interesting.

A couple of possibilities…

I /think/ you said that it /did/ get blocked, if you just put “/advert…” in the browser's address bar, but not when you used the fully qualified url. So perhaps that particular pattern only matches domain-less paths.

Another possibility is that since its basically trying to block ads on the pages you visit, it may only block xhr and iframe (and perhaps popup) requests.

But this has made me realize that I need to choose my server-side filenames and paths very carefully – the adblock blacklist that I found had a /huge/ list of things it would block. I should probably install it just to make sure Im not violating any of them…

Mark

I'll take a look at this… but unless IE is reporting the positions incorrectly, Math.round is the wrong function. It /has/ to truncate to get the correct result.

Mark

Using Fiddler (on Windows) I can verify that the AJAX request is never made so it can't be a blocking issue.

I think it /must/ be a blocking issue of some kind – because the url is passed direct to $.ajax, which (I've checked the source code) doesnt do any url checking before making the xhr request.

But if the request isnt even being sent, it would have to be on the client side… could it be your firewall/antispyware/add-blocking software? What browsers have you tried?

Also, I guess you put a full url into the browser – have you tried doing that for the grid url parameter?

Mark

I had a similar issue (with different urls, though). It turned out to be mod_security running on my server. It basically checks the url for certain patterns, and rejects them if they match. I had a long battle with my service provider to get them to drop it…

Since Im almost certain there's nothing on the client side that cares about the url, I'd guess you have the same issue.

One way to test this is to just type the url into the address bar – if it fails, you know where the problem is…

Also, if you have access to your server logs, you should be able to find the errors in there…

Mark

Yes, you're right – it would be good if the grid supported it directly.

But a lot of people want to use the prebuilt compressed grid code – so a solution that doesnt involve changing grid code is also useful.

Mark

I think the way it works is that