310447 - Part of patch for bug 11011 breaks layout of My Yahoo!

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[mv_van_rantwijk]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050920 MultiZilla/1.8.1.0n SeaMonkey/1.1a
Build Identifier: 

A part of the patch for bug 11011 (display: none !important;) breaks the layout
of My Yahoo!

People expect the buttons on a certain location, but that no longer applies in
builds with this patch. 

For example: the sign out link/button is normally positioned in the middle of
the page, at least before this patch went in, but now it is at the start/left
side of the page (when you block some of the images on that page).

I'm not the only one blocking images, so this is probably getting (very)
annoying for others a well. 

Is there a work around that can be used in userChrome.css until this issue is
solved?



Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Is there a work around that can be used in userChrome.css until this issue is
> solved?

No.  And I'm not sure we really want to solve this issue.  This change in
behavior was very much purposeful, and I'd like to keep it unless it causes a
huge problem (and consistent repositioning of a button which the user will get
used to after a few days is not huge).

If we do decide that the images should take up space (but not be painted) then
we need to change the code at
http://lxr.mozilla.org/seamonkey/source/layout/style/html.css#418  I like that
approach less because it'd make part of the image clickable (the part where the
<a> is).

Comment 2

[mv_van_rantwijk]

(In reply to comment #1)
> > Is there a work around that can be used in userChrome.css until this issue is
> > solved?
> 
> No.  And I'm not sure we really want to solve this issue.  This change in
> behavior was very much purposeful, and I'd like to keep it unless it causes a
> huge problem (and consistent repositioning of a button which the user will get
> used to after a few days is not huge).

So the end-user has no control/options. Brilliant!

What about unblocking images with right-click? This option was available in
almost every Mozilla build, until bug 11011 was fixed. If taking away a long
standing feature isn't huge, what is?

BTW: will you also remove  that menu item?

The page layout should never be changed by the browser, or the end-user should
at least have (some) control over it!

Comment 3

[Boris Zbarsky [:bzbarsky]]

It's not too hard to write an extension that will change this behavior.  But
yes, in general the end user has no control over some parts of the layout engine
(eg alt text tooltips).  That's just the way it is.

> What about unblocking images with right-click?

This is definitely a problem.  People want to do this on the one hand, but not
trigger image links on click on the other.  I really don't see a good solution
to both problems as far as rendering goes (though perhaps we could fake
something with event handlers), and there was a _lot_ of clamoring for not
triggering image links.  Again, this should be up to the UI folks to decide; bug
11011 provided the mechanism; it's not dictating policy.

> BTW: will you also remove  that menu item?

That's not part of Gecko; it's up to the UI folks to decide what behavior they want.

> The page layout should never be changed by the browser

The page layout is completely determined by the browser, dude.  I'm not sure
what you mean by "changed" in this context.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

don't we have -moz-user-input or somesuch which could maybe be used to disable
link triggering?

Comment 5

[[e-mail]]

Maybe an XBL preventdefault="true" binding (c.f. scrollbar-base)?

Comment 6

[mv_van_rantwijk]

(In reply to comment #3)
> It's not too hard to write an extension that will change this behavior.  But
> yes, in general the end user has no control over some parts of the layout engine
> (eg alt text tooltips).  That's just the way it is.

But you could change that, right? You have the power to change it ;)

> > What about unblocking images with right-click?
> 
> This is definitely a problem.  People want to do this on the one hand, but not
> trigger image links on click on the other.

I sure hope it is.

> I really don't see a good solution
> to both problems as far as rendering goes (though perhaps we could fake
> something with event handlers), and there was a _lot_ of clamoring for not
> triggering image links.  Again, this should be up to the UI folks to decide; bug
> 11011 provided the mechanism; it's not dictating policy.

It is a dictating policy, as long there's no option to disable this behavior.

> > BTW: will you also remove  that menu item?
> 
> That's not part of Gecko; it's up to the UI folks to decide what behavior they
want.

The patch simply eliminates that menu item, but I sure hope that someone wakes
up and blocks the patch before it's too late. 

> > The page layout should never be changed by the browser
> 
> The page layout is completely determined by the browser, dude.  I'm not sure
> what you mean by "changed" in this context.

Yes, but most web designers/autors rely on their layout, including the images,
so that might become a problem one day.

Comment 7

[Hixie (not reading bugmail)]

Is there a testcase for this bug showing the problem?

Comment 8

[Boris Zbarsky [:bzbarsky]]

The testcase is blocking any image via the context menu option or the Image
Manager UI or menu options in SeaMonkey.  With the patch to 11011 such images
become display:none, whereas before they became replaced inlines that were
transparent.

Comment 9

[mv_van_rantwijk]

Attachment: This is how it should be (Google)

Comment 10

[mv_van_rantwijk]

Attachment: but this is how it looks now

You will have to agree that this patch/change makes it (very) hard to use these
numbers.

Comment 11

[mv_van_rantwijk]

(In reply to comment #3)
> It's not too hard to write an extension that will change this behavior.  But
> yes, in general the end user has no control over some parts of the layout engine
> (eg alt text tooltips).  That's just the way it is.

You mean by writing an extension that replaces html.css? 

There's already adblock/flashgot (or whatever add-on/extension it was) that also
modifies this file, so having another extension will probably just break one or
both of these extensions (just think about what happened when the marguee add-on
did this).

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #11)
> You mean by writing an extension that replaces html.css? 

that registers an agent sheet using nsIStyleShetService...

Comment 13

[mv_van_rantwijk]

(In reply to comment #12)
> (In reply to comment #11)
> > You mean by writing an extension that replaces html.css? 
> 
> that registers an agent sheet using nsIStyleShetService...

Ah, nsIStyleSheetService.idl now that's quite an interesting concept. Thank for
the hint.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Well, now.  The google page would look like your "this is how it looks now"
picture in standards mode with images disabled too.  It's just somewhat badly coded.

And that said, the probability of people suppressing images from google is about
0.  I'm not saying you can't manufacture testcases where using display:none
decreases the usability of the page.  I'm saying that in general I believe it
increases usability (note that adblock also sets things to display:none when it
blocks them, for example; this is not an accident).  But it's up to the UI
people to make the final call on what is effectively a UI matter.

Comment 15

[mv_van_rantwijk]

(In reply to comment #14)
> Well, now.  The google page would look like your "this is how it looks now"
> picture in standards mode with images disabled too.  It's just somewhat badly
coded.

Care to explain why the layout isn't changed when you set the docShell property
for images, so the image blocks are not always completely hidden. Why this
inconsistently if I may ask?

> And that said, the probability of people suppressing images from google is
about 0.  

It seems that you are ill informed. We have almost 190.000 paid customers of our
content blocker, and there are plenty other public filter lists that do in fact
block images from Google, be it proxy or not. Also, care to read the over 400
e-mails with complaints about this 'feature' that we received in the first week
only?

I'm not saying you can't manufacture testcases where using display:none
> decreases the usability of the page.  I'm saying that in general I believe it
> increases usability (note that adblock also sets things to display:none when it
> blocks them, for example; this is not an accident).  But it's up to the UI
> people to make the final call on what is effectively a UI matter.

What exactly makes you think that it increases the usability for end users?

Comment 16

[Boris Zbarsky [:bzbarsky]]

> What exactly makes you think that it increases the usability for end users?

The fact that they can't accidentally click on ad links they don't even see. 
This was the #1 complaint about our image blocking implementation last I checked.

Comment 17

[mv_van_rantwijk]

(In reply to comment #16)
> > What exactly makes you think that it increases the usability for end users?
> 
> The fact that they can't accidentally click on ad links they don't even see. 
> This was the #1 complaint about our image blocking implementation last I checked.

Ok I agree, that sound very reasonable, but what about comment #4 and comment
#5? Would something like that be possible?

I still think that there should be a preference for this, because you basically
killed a nice feature (right click on images). Oh, and doesn't that in fact
dilute the usability for end users by a factor 100?

Comment 18

[Boris Zbarsky [:bzbarsky]]

I don't know enough about either -moz-user-input or the xbl stuff to answer
those questions.  And again, I'm not a usability expert; I'm just providing the
core support for whatever the UI wants here.  Notice that all the things we're
talking about can now be done in CSS instead of having to change C++ code --
that was the point of bug 11011.

Comment 19

[mv_van_rantwijk]

(In reply to comment #18)
> I don't know enough about either -moz-user-input or the xbl stuff to answer
> those questions.  And again, I'm not a usability expert; I'm just providing the
> core support for whatever the UI wants here.  Notice that all the things we're
> talking about can now be done in CSS instead of having to change C++ code --
> that was the point of bug 11011.

I will wait for the UI peers to explain their vision, and thank you for your
time/help/info so far! 

Comment 20

[:aceman]

There must be a way to unblock images with the rightclick menu. And there must
be an indication that come images were blocked, and where they are. The position
on the page and their source URL is crucial for the user to determine if they
possibly don't deserve to be unblocked.

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

The aspect of this bug that's asking for indication of when images are blocked
is now being tracked in bug 310447.

The part that's asking for the equivalent area of the image to still be spaced
out in terms of layout ... is what this baby's all about!

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

plz ignore comment 21, I used the wrong bug #

The aspect of this bug that's asking for indication of when images are blocked
is now being tracked in bug 310492.

The part that's asking for the equivalent area of the image to still be spaced
out in terms of layout ... is what this baby's all about!

Comment 23

[Boris Zbarsky [:bzbarsky]]

So frankly, I'm tempted to wontfix this.  I don't see much value in preserving layout when you're blocking images, generally speaking.  Esp. since we can only do so if the site has specified a width/height for the image.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm afraid I don't have an opinion on this. Hard to believe, I'm sure.

Comment 26

[Mike Palumbo]

Apologies for coming in so late on this.  My issue here is that I want images on certain websites turned off, but I don't want their anchors removed.  By forcing display:none, anchors under the images disappear entirely, because the image is removed from page layout, taking away all of the website functionality.  I can't even use FF3 because of this, without turning images on and off browser-wide.  Total PITA.

If this is wontfixed, looks like I'll be sticking with 2.x for a long time.

Comment 27

[Boris Zbarsky [:bzbarsky]]

The premise of the current code is that the sites images are turned off for are "ad" sites: sites where the user wants no indication that the image even exists.  That's the most common use of the functionality, as I understood it.  Note that completely hiding blocked ad images was one of the most common requests dealing with the image blocking functionality in Firefox 2.x.  See the explicit comment 3 mentions of people not wanting to able to click on exactly the links you want to be able to click.  There's no way to satisfy both sets of users, so the question is which set is bigger...

The current core code does differentiate between "all images from this server are blocked" (in which case the image is display:none) and "this specific image is blocked" (in which case the alt text is shown).  The firefox image blocking does the former.

Perhaps we need to have two different reasons for blocking all images from a given server, but then the UI would need to differentiate between the two situations.  You might want to consider raising a Firefox UI bug about that, though I doubt that's easy to express in the UI.

Also note that it's pretty simple to create an extension that adds a menuitem that does exactly what you want.  If there's actually sufficient demand for it, I'm pretty sure it'll happen.

Note that security updates for 2.x will likely stop about 6 months after 3.0 is released; I wouldn't recommend using 2.x past that point.

Comment 28

[Mike Palumbo]

Thanks for the reply.

Perhaps I'm an exception case, but I use the AdBlock extension to get rid of ads, and anytime I use the "Block images from this server" functionality is because I'm at work and want a text-only version of certain sites, everything from Slashdot to various local blogs.  The images are still core site functionality, I just don't want them showing up.

I can't imagine a way of designing a UI to differentiate between the two behaviors.  I suppose I've grown very acclimated to the way I use FF2, so FF3 completely breaks a lot of sites that I frequent.

I'll have to see if there is a way around this, either by using adblock instead of internal image blocking or writing something myself.  I see where other people are coming from, but I find the layout changes quite annoying.  Oh well!

Sorry for the email, all.