Open Bug 377396 Opened 17 years ago Updated 1 year ago
Unused tabs should be disabled not hidden
22.45 KB, image/png
23.44 KB, image/png
22.58 KB, image/png
6.37 KB, patch
|Details | Diff | Splinter Review|
42.33 KB, image/png
In the new page info dialog, the feeds tab is removed when there is no feeds on the page. This happens after the dialog is visible and causes the icons to jump around in a disconcerting manner. I suggest that the feeds icon be disabled or something which should be less of a change, and not leave me wondering what's missing as I did before.
We have the same issue for the Media tab.
Summary: Feeds tab should be disabled not hidden → Unused tabs should be disabled not hidden
So yes its actually the media tab that's causing the jumping around in this case. I imagine that a simple wallpaper patch could just default the media tab to visible and feed tab to hidden, I imagine that the vast majority of webpages would fit that setup so it would only be the exceptions where things would be poor. But really disabling them is a far better solution I think.
(In reply to comment #2) > But really disabling them is a far better solution I think. I prefer that solution too. I will make a patch for this bug once bug 377397 and bug 377440 are fixed.
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: PC → All
Requesting review. I don't know if this needs ui-review too...
Assignee: nobody → f.qu
It does, we may also need images for the disabled state
(In reply to comment #5) > It does, we may also need images for the disabled state Tada
Thanks Michael, these are only correct for Winstripe though (actually, I think they might be too dark), Pinstripe doesn't use grayed-out icons.
(In reply to comment #6) > Created an attachment (id=261931) [details] > Images with disabled states Thanks. After comparing with the icons of the toolbar, I think too that they might be a bit too dark. Actually, I had already asked a friend to add the disabled state to the icons file, I should have noted that in the bug :-(. I will soon attach an image file for pinstripe and another one for winstripe.
New patch coming, probably tomorrow...
Comment on attachment 262164 [details] [diff] [review] patch v2 I forgot to diff pageInfo.xul in this patch, but the changes in it are the same that in attachment 261826 [details] [diff] [review].
17 years ago
Attachment #262165 - Flags: ui-review?(beltzner)
I'm not sure why the tabs should be disabled. The content on the tabs themselves still functions, and they faithfully represent the fact that there is no content there. If those buttons took some action on media or feed content, then they should be disabled when the content isn't present. Since they are actually taking action on the page, and describing the media and feed content available, they should remain as active buttons, and their pages should indicate that there is no content available.
That sounds fine by me. All I'm really interested in is getting rid of the flickering on dialog load.
Comment on attachment 262165 [details] Screenshot with disabled tabs per comment 14, I'm suggesting this morph into "unused tabs should not be hidden"
Attachment #262165 - Flags: ui-review?(beltzner) → ui-review-
The main point of hiding unused tabs was to avoid the user clicking on each tab to discover then that it is empty. If you don't want to hide tabs, and don't want to disable them, how can we visually inform the user that clicking that tab is worthless? Another idea that I had, but I don't really like it, is to display a number in the tab title, for example we would have: Media (15), and Media (0) would mean that it is not worth clicking the tab. I don't like this idea because changing dynamically the title of a tab seems unusual, and I think the number changing repeatedly while Page Info is loading would be even more distracting for the eyes that tabs appearing like now. Disabling useless tabs was my prefered solution because it doesn't catch the eyes too much, and allows users to discover what the possible tabs are. Any other idea?
Mike seems to have made the choice in comment 14 to just show the tabs. I'm not sure why we need to inform the user what is on those tabs before they click on them.
Flags: blocking-firefox3? → blocking-firefox3+
Florian, this is blocking Firefox 3 and currently assigned to you. Are you going to be able to get to it in time for M10?
(In reply to comment #19) > Are you going to be able to get to it in time for M10? > Yes
Making all tabs always visible doesn't seem to be the right thing to do. Feeds and Media tabs can be displayed empty when there is no content to show in them, but we also sometimes hide the Permissions and Security tabs. The Permissions tab is hidden for chrome:// or data:// urls. The Security tab is hidden when displaying frame info because of bug 149207.
(In reply to comment #21) > The Permissions tab is hidden for chrome:// or data:// urls. Sure, I'm fine with the Page Info dialog looking different for different kinds of pages. But, it *should* look the same for all web pages, chrome:// pages and data:// pages. > The Security tab is hidden when displaying frame info because of bug 149207. The right solution there is to explain why we don't have security info, or better yet, figure out how to get the user to be able to see the security info for a frame (perhaps add in buttons that trigger the frame->View Security Info functions for all available frames) Similarly with Feeds, if the page doesn't have any, the tab could even still be enabled and just say "No feeds available on this page". If it's not global enough to be on all pages of a type, it probably doesn't deserve a tab.
(In reply to comment #22) > (In reply to comment #21) > > The Permissions tab is hidden for chrome:// or data:// urls. > > Sure, I'm fine with the Page Info dialog looking different for different kinds > of pages. But, it *should* look the same for all web pages, chrome:// pages and > data:// pages. Presumably so long as it doesn't cause the visual artefacts that I filed this bug about in the first place?
Target Milestone: Firefox 3 Mx → Firefox 3 M11
16 years ago
Priority: P5 → --
What is the status of this patch?
(In reply to comment #24) > What is the status of this patch? The patch (probably bitrotted now) was based on the idea in comment 0 and 2. I'm no longer working on this (I should have reassigned it to nobody earlier, sorry). Feel free to take it if you agree with the decision in comment 14.
Assignee: florian → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.