[Done] Attaching ABP blockable item window to the bottom

[chewey]

This is great! It might actually convert me to use the attached window...

A probably unrelated detail: ABP fails to show the image in the tooltip of
some background images, see e.g. http://www.sueddeutsche.de/.

From the gifs beginning with http://pix.sueddeutsche.de/img/layout/ecke_,
only ecke_unten_links.gif is shown in the tooltip, the other three tooltips
are text-only. This happens with several other images on sueddeutsche.de too.

Opening them in a new tab however displays the image, so the file is there.
Also, knowing what the image looks like, it can be found in the page.

Another thing: If an image is in a hidden element, clicking its line in the blockable
items list does nothing - not scrolling to its position, no red blinking frame.
Well, duh - that's because it is nowhere to bee seen of course, but it had me
confused for a moment. Is there a way to detect if an image is visible or not and
treat the invisible-by-element-hiding ones as "hidden"?

[Wladimir Palant]

You are right, this is unrelated. The tooltip only shows images that can be found in the cache to prevent sending a new request to the server. sueddeutsche.de sends Expires headers in the past for some of its images, consequently these images aren't stored in cache and cannot be displayed.

As to invisible images: detecting whether an image is visible on the page should be possible but telling whether it was one of our element hiding rules at work - that's pretty tricky. And even if we could find it out, at the moment I don't see how this will give us a consistent user interface.

[chewey]

The tooltip only shows images that can be found in the cache to prevent sending a new request to the server. sueddeutsche.de sends Expires headers in the past for some of its images, consequently these images aren't stored in cache and cannot be displayed.

Ah, I didn't find that. Thanks for the analysis. I actually have a contact at
sueddeutsche.de's machine room, I'll try to make them change that.

As to invisible images: [...] telling whether it was one of our element hiding rules at work - that's pretty tricky.

That's what I thought too, but I wanted to bring up the finding. Who knows, maybe
one day you'll come up with an idea as ingenious as the one for the EH hitcounters.

And even if we could find it out, at the moment I don't see how this will give us a consistent user interface.

That's the easy part: Just make a hidden image displayed as "hidden" too.

[Wladimir Palant]

That's the easy part: Just make a hidden image displayed as "hidden" too.

Not that easy: you can have the same image multiple times on a page, and only some instances of this image will be hidden.

[chewey]

Not that easy: you can have the same image multiple times on a page, and only some instances of this image will be hidden.

Oooooh, very good point, I missed that.
I'll shut up then...

[alta88]

The current development build shows the list of blockable items at the bottom of the browser window. It seems to work well, this change should still be considered experimental however. Please test.

doesn't work with Split Browser installed, regardless of whether any splits are active. i notice you just add a vbox after #content; there are quite a few levels of overlay already in there.

however. i discovered that creating a split, and putting in a url of

Code: Select all

chrome://adblockplus/content/sidebar.xul

gives the Adblock not installed error *initially*. a subsequent page refresh will indeed display blocked items. and even cooler, in a second Split Browser pane, refreshing that pane's page will list *that* page's blocked items.

there are bits of quirkiness, like items don't blink and after some time some seem to disappear. unlike in sidebar, focus on a tab/pane doesn't autorefresh the list, need a reload. maybe a look could make it work, it's 98% there.

big picture - it doesn't make sense for every extension to create this kind of split. Split Browser does it very generically, in as many ways as wanted, and is good enough to be part of Fx core so Sidebar can by anywhere, etc etc., and extensions can have their xul drag dropped into any 'pane'.

jmo. but i built a sandbox like this 7 years ago in java - and would like to see Fx get closer to being an app OS with stuff like this.

[Parson]

The current development build shows the list of blockable items at the bottom of the browser window. It seems to work well, this change should still be considered experimental however. Please test.

Thanks, works fine here. Very much appreciated.

[Wladimir Palant]

@alta88: Works fine for me, with Split Browser 0.3.2007012303. Of course the list only applies to the real content window then, not to any of the splits.

[alta88]

hmm. i have 0.3.2007020401, it works with a different much fewer extensions profile, but not the main one. could it be AiOS? changing the pref to detached makes it show up fine, but toggling reattach makes it disappear. no console errors.

it would be nice, as i said, to get it to work with any pane completely - in fact it does pretty much now.

[alta88]

disabling Split Browser lets it work - so it's compatibility with the latest version..

[Wladimir Palant]

I have now seen what you mean - things get crazy when you start with Split Browser already active (stored a split from the last run). As to blockable items attaching to the wrong window - I fixed this, now this list really only shows the "real" content window.

[alta88]

well, i was actually saying having the list from whatever pane is active is a good thing! the active pane's page *is* the 'real' content - so the fix would be to have focus on that pane show the list (like selecting a tab does now) rather than having to reload.. (plus the other quirks above)

using SB, you could have the blocked items above the tabbed browser, not just below. that's my rant ;D

how would i open blocked items? i'd make a button and drag the xul onto a part of a page where i wanted it, like this.

[Wladimir Palant]

Sorry, that was most certainly a bug (not my bug, Split Browser is doing crazy things, but nevertheless). A consistent user interface cannot work this way.

Edit: The remaining weirdness (blockable items list appearing on the left and disappearing forever once the split is closed) seems to be XBL bugs - Split Browser does extensive XBL manipulation. I don't see an obvious way to work around this so that I can only delegate this issue to the Split Browser author.

[alta88]

i guess i don't see why you think displaying items from any focused pane is undesirable functionality, or why a simple listener on the focused pane can't be used. also not sure what would qualify as 'crazy'.

a unified interface is fine, but now it's become limiting to customization.

adding panes across the mozapps is a free for all since it hasn't been made generic (which something like SB could solve). so you're going to just get collisions. for example, ABP blockable items doesn't work in Tb with xSidebar installed, nor do i think there is a 'consistent' interface there. architecturally, you could just (also) provide a blockable items xul that loads in any #document page, no?

[Wladimir Palant]

Adblock Plus filters any content document loaded, it is universal regardless of what crazy extension you use. The list of blockable elements however needs some (one!) window it can attach to and it needs a clear way to know when it has to switch to another window. And I see only one meaningful way: the main content window is the only one we care about even though extensions might add a dozen others that are visible at the same time. Anything else will only cause confusion because it isn't clear which window the list applies to right now.

As to the craziness of Split Browser: I meant the implementation. It manipulates XBL dynamically which is known to have issues in Gecko 1.8. I think XBL has been somewhat improved on trunk but when I install Split Browser there I get the "no XBL binding for browser" message - that was probably too much reorganizing the user interface structure. Note that this breaks Firebug as well, not only Adblock Plus. Split Browser also changes the primary content window "randomly" which is likely to break sidebar extensions - as happened to Adblock Plus. I solved this by no longer relying on the window.content variable (something I only had to do in Songbird so far).

My conclusion: trying to work around the quirks of Split Browser is too much effort. In the next release I will list it under known issues, sorry.