Open Bug 416557 Opened 12 years ago Updated 6 years ago
Remove "Block images from www
.site .com" from Page Info
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020908 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020908 Minefield/3.0b4pre Go to: http://vancouver-webpages.com/plugins/midi.html Reproducible: Always Steps to Reproduce: 1. Go to: http://vancouver-webpages.com/plugins/midi.html 2. Go to: Page Info > Media Actual Results: See irrelevant options: Dimensions, Block Images from vancouver-webpages.com, Media Preview. Expected Results: No irrelevant options should appear. If the page _shows_ images, Dimensions, "Block Images from....", and Media Preview should only appear when selecting an image.
Not sure what we want to do for "Dimensions" and the Media Preview area, but the "Block Images from <hostname>" check box should definitely be hidden in this case.
Status: UNCONFIRMED → NEW
Ever confirmed: true
IMO this bug should be closed INVALID. (In reply to comment #0) > Preview should only appear when selecting an image. Exactly. There IS always one image/media selected (grey list item background on windows), that's why we are showing the full preview for that selection. It doesn't have FOCUS, because the focus sits on the Media pane header where you just clicked. That's expected behaviour, too (apart from the fact that the dotted focus indicator is missing, as mentioned in bug 223040 comment #15, section 5). Compare similar behaviour in Thunderbird: In 3-pane-view, select a message first (=image). Then set focus on the containing folder (=media tab). You can still see the selected message in preview, and you can also act on it (reply button in new header pane etc.) without refocussing the message beforehand. I must admit I was about to propose something else (more similar to your request), but this feels much better. Furthermore, it's much more inviting for the user to see what you can actually do with the media pane (image data, preview etc.) than just showing everything blanked out, disabled, or even showing nothing. The only excuse for not showing image-related data at first would be if there was no selection AND we can offer some sort of useful information what you can do here (similar to welcome screen in Thunderbird preview). So at most, this could be an enhancement. Personally, I think the real thing (actual preview and image data) says more than words. I'd appreciate a confirmation from someone with the powers that it's ok to invalidate this bug, or just invalidate yourself.
Severity: normal → trivial
Status: NEW → UNCONFIRMED
Ever confirmed: false
Hardware: x86 → All
Which is more like saying this can't stand as a bug, but may or may not be accepted as an enhancement... :)
Hiding the "Block Images from <host>" checkbox when the selected media is not an image seems like a valid request to me.
(In reply to comment #4) Thanks Florian, you are right! It's a complete misunderstanding on my part because the current summary of this bug is not very clear and can easily be misunderstood if you take focus literally ("Page Info > Media should not focus on images UI"). My mistake, because I skipped step 1 :( Sorry for the noise. (In reply to comment #2) > IMO this bug should be closed INVALID. Please forget my comment #2. I'll change the summary to something less ambiguous. There might be non-image media types that have dimensions (videos). Are there any non-image media types that can be previed? Does "Block Images..." really block only images or other media content as well? Is there any way to block other media content from specific hosts?
Severity: trivial → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Page Info ▸ Media should not focus on images UI → Page Info > Media should not use images UI for non-image media types (Block images from <hostname>, dimensions etc.)
This should be fairly simple. I will get around to this soon since we are previewing more media types.
Assignee: nobody → mozilla.bugs
Status: NEW → ASSIGNED
I am changing this to remove the image blocking option altogether since it has been removed in Bug 514739 and according to the discussion there ( https://bugzilla.mozilla.org/show_bug.cgi?id=514739#c25 ), the Page Info and Preferences UI should be removed as well. I will handle removing it from the Page Info window, but I will not handle the Preferences window. I think we should still show dimensions on plugins since we are changing how plugins behave in Bug 515549 and Bug 574545 such that the dimensions field will become useful when those bugs land (though we do have the ability to disable that field altogether since Bug 448630 landed if needed).
Summary: Page Info > Media should not use images UI for non-image media types (Block images from <hostname>, dimensions etc.) → Remove "Block images from www.site.com" from Page Info
Bug 514739 was only about removing a piece of confusing UI, it doesn't say that the entire image blocking functionality is useless. I think there is quite a bit more discussion necessary before removing it altogether.
I hope you are not going to remove the backend since there are other consumers other than Firefox you know...
Existence of "other consumers" does not preclude removing the feature.
Hiding the checkbox when the selected item isn't an image is a fine idea. So is hiding any of the other items when they don't apply to the selected item, such as the dimensions when the selected item is an <audio> tag. A better idea might be to include temporal dimensions when they're available. The dimensions of a <video> are the width, height and duration of the video content it displays. That should be a different bug, however.
Regardless of what is decided--whether this should be removed or modified--I don't have time to work on this bug anymore, and so I am unassigning myself.
Assignee: mozilla.bugs → nobody
Status: ASSIGNED → NEW
I don't agree with globally removing image blocking UI from Page Info when displaying a webpage.
So, no activity from the reporter since the posting of the bug, and it's debatable at best that "Block Images from..." is irrelevant; let's just get it CLOSED INVALID for good. fx4 was annoying enough for removing that from a convenient context menu (bug #514739)...
Please advise. This is now inconsistent. The check boxes are there and may check/uncheck but do nothing if images are already blocked. Bug 851701 has now been fixed. It is now possible to block images by using about:config to set the value of the pref permissions.default.image STR Block images by setting permissions.default.image =2,then navigate to Page Info. Now navigate to Page Information |Media|The check boxes still exist and may be checked or unchecked. There is an option Load Images Use default  Uncheck this The Radio buttons Allow () Block () become bold and may be expected to work. Allow may be selected. It however has no effect. This bugzilla page contains images and may be used to demonstrate. Either the options should be removed, as in the current title of this bug. OR The buttons should be greyed out or otherwise removed or marked inactive if images are blocked. My above suggestion possibly would require filing a new bug, but that is rather pointless if this bug is to be actioned.
(In reply to John Hesling [:John99] from comment #17) > Please advise. > > This is now inconsistent. The check boxes are there and may check/uncheck > but do nothing if images are already blocked. > > Bug 851701 has now been fixed. > It is now possible to block images by using about:config to set the value > of the pref permissions.default.image How is this related to the fixing of bug 851701? Presumably the same situation could be activated by using the controls in the preferences in previous versions. I don't think anything has become inconsistent "now" - if it's inconsistent, it would have been inconsistent before.
(In reply to :Gijs Kruitbosch from comment #18) > (In reply to John Hesling [:John99] from comment #17) > > Please advise. > > > > This is now inconsistent. The check boxes are there and may check/uncheck > > but do nothing if images are already blocked. > > > > Bug 851701 has now been fixed. > > It is now possible to block images by using about:config to set the value > > of the pref permissions.default.image > > How is this related to the fixing of bug 851701? Presumably the same > situation could be activated by using the controls in the preferences in > previous versions. I don't think anything has become inconsistent "now" - if > it's inconsistent, it would have been inconsistent before. It is related to Bug 85170 because Bug 85170 blocked this bug. There was no need to use the preference prior to Bug 85170 the UI toggled the preference There is now no method of blocking all images loading, from the UI (without using add-ons). There are also no exceptions list or exceptions buttons, they have been removed now. Yes I now realise it was inconsistent before. I checked with an ESR fx10 and that shows similar behaviour to fx23, although it had the additional exceptions buttons and list. Inconsistency still stands. If these buttons are to be left on PageInfo then they need fixing, and that apparently requires a new bug. (I did not see any existing bug) But if a bug to fix them is contemplated - does that go against the UX principles in Bug 851698 - (checkboxes-that-kill) - no point fixing unless this bug is Wontfixed because the option will be removed (Not checked but maybe some other options on Page Info are also defunct.)
You need to log in before you can comment on or make changes to this bug.