425998 - History items (Today, Yesterday, etc.) should use a calendar icon

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

The top level items in the history sidebar "Today, Yesterday, 2 Days Ago, 5 Days ago, Older than 6 days ago" should use the icon /places/calendar.png

This will be landing for windows xp and vista soon.  Linux and OS X should use a similar image in the same location of pinstripe and gnomestripe.

Comment 1

[Reed Loden [:reed]]

Linux now has this icon landed and ready for use in gnomestripe, as per bug 418868, comment #66.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

Requesting blocking since we have the icons.

Comment 3

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

OSX has a clock icon already - do we know where it is?

Not blocking, but an obvious easy-to-take if someone can post a CSS fix that points to the new icon.

Comment 4

[Lim Chee Aun]

The CSS fix, tested on Firefox3b4:

#historyTree treechildren::-moz-tree-image(title, folder) {
  list-style-image: url("chrome://browser/skin/places/calendar.png") !important;
  -moz-image-region: rect(0px, 16px, 16px, 0px) !important;
}

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

>OSX has a clock icon already - do we know where it is?

The clock is unrelated to this change.

Comment 6

[mcdavis941 (sporadically reading bugmail)]

I can turn Lim Chee Aun's code into a patch.  Alex, could I see the icons, so I know what states (hover, open, etc.) to code for?

Comment 7

[Lim Chee Aun]

(In reply to comment #6)
> ... so I know what states (hover, open, etc.) to code for?

Wow, even a calendar icon have states? Is it necessary?

Comment 8

[mcdavis941 (sporadically reading bugmail)]

>(In reply to comment #6)
> Wow, even a calendar icon have states? Is it necessary?

Good question, I don't know.  Probably not hover, since nothing else does that I can see, but maybe open because it's a folder.

I didn't ask ... do you want to take this bug?  I assumed you would already have if you wanted to, but maybe that was my mistake.

Comment 9

[Lim Chee Aun]

(In reply to comment #8)
> >(In reply to comment #6)
> > Wow, even a calendar icon have states? Is it necessary?
> 
> Good question, I don't know.  Probably not hover, since nothing else does that
> I can see, but maybe open because it's a folder.

"Open a calendar" icon? But well, I'm not really a fan of open/closed folder icons anyway since I think they're useless and there are already open/closed twisties. Depends on devs then.

> I didn't ask ... do you want to take this bug?

Feel free to take it. I don't know how to write a patch though.

Comment 10

[mcdavis941 (sporadically reading bugmail)]

Attachment: places.css add calendar icon v1

Original code by Lim Chee Aun

Comment 11

[Reed Loden [:reed]]

Mind including gnomestripe in your patch, too?

browser/themes/gnomestripe/browser/places/places.css

#historyTree treechildren::-moz-tree-image(title, folder) {
  list-style-image: url("chrome://browser/skin/places/calendar.png");
}

Comment 12

[mcdavis941 (sporadically reading bugmail)]

(In reply to comment #11)
> Mind including gnomestripe in your patch, too?

Right.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Luna calendar

Example of the luna calendar (single state)

Comment 14

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Example of the aero calendar

Example of the aero calendar (single state)

Comment 15

[mcdavis941 (sporadically reading bugmail)]

Attachment: places.css add calendar icon v2

For gnomestripe, pinstripe, and winstripe.

Reed: confirmed that -moz-image-region: auto was required on winstripe.

Comment 16

[Reed Loden [:reed]]

(In reply to comment #15)
> Reed: confirmed that -moz-image-region: auto was required on winstripe.

No, I was just asking you if it was required or not... Did your testing show that it was? If it isn't, the line can be dropped, but if it is, we need it. :)

Comment 17

[Reed Loden [:reed]]

oh, you're answering me! n/m... *sigh*

Comment 18

[Michael Ventnor]

Correct me if I'm wrong, I'm just looking at the code, it seems you apply a calendar icon to every folder? What if the user changes it to by Site or Date & Site?

Comment 19

[Lim Chee Aun]

(In reply to comment #18)
> Correct me if I'm wrong, I'm just looking at the code, it seems you apply a
> calendar icon to every folder? What if the user changes it to by Site or Date &
> Site?

Ugh, you're right. The code applies the calendar icon to every folder! In that case, the code needs to be revised and I'm not sure if something like '
treechildren::-moz-tree-image(title, calendar)' exists or not.

Comment 20

[Marco Bonardo [:mak]]

imo that should be fixed in places frontend code providing an attribute for history containers like has been done for tag containers (they can be recognized using PlacesUtils.nodeIsDay() or checking parent result type).

Comment 21

[mcdavis941 (sporadically reading bugmail)]

(In reply to comment #20)
> imo that should be fixed in places frontend code providing an attribute for
> history containers like has been done for tag containers (they can be
> recognized using PlacesUtils.nodeIsDay() or checking parent result type).
> 

Yeah, there needs to be a new property to distinguish the two cases.  Checking all the existing properties (that I could find), there isn't any that was found on a folder representing a date (meaning it should have a calendar icon) that wasn't also on a folder representing a site (with pages beneath it) in the history sidebar.  

I'd vote for something like 'dateFolder'.

Comment 22

[Marco Bonardo [:mak]]

everything should be ready now

Comment 23

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

mcdavis: so, if everything's ready, can we get that patch?

Comment 24

[mcdavis941 (sporadically reading bugmail)]

Sure, today.

Comment 25

[mcdavis941 (sporadically reading bugmail)]

Where should I be looking for the calendar icon for Pinstripe?  It looks like it hasn't landed yet, is that right?

I see Alex's comment about it being in the same location for OSX and Linux, I'm just double-checking.

Comment 26

[mcdavis941 (sporadically reading bugmail)]

Attachment: update places.css for winstripe and gnomestripe to use calendar icon v3

Leaves off OS X changes in favor of Bug 430693

Comment 27

[Marco Bonardo [:mak]]

IIRC there is another reference to day containers maybe in browser.css?

Comment 28

[mcdavis941 (sporadically reading bugmail)]

(In reply to comment #27)
> IIRC there is another reference to day containers maybe in browser.css?
> 

That's true.  Does that case occur in the UI?  I saw the rule, but do you ever have a dayContainer as a bookmark item?

Comment 29

[Marco Bonardo [:mak]]

you could create a saved search with those in, maybe in the toolbar or in the menu

Comment 30

[mcdavis941 (sporadically reading bugmail)]

(In reply to comment #29)
> you could create a saved search with those in, maybe in the toolbar or in the
> menu
> 

thanks.  i'll update to handle this case.

Comment 31

[mcdavis941 (sporadically reading bugmail)]

Attachment: browser.css and places.css v4

Comment 32

[Marco Bonardo [:mak]]

 treechildren::-moz-tree-image(title, query, dayContainer) {
   list-style-image: url("moz-icon://stock/gtk-directory?size=menu");
 }
 
+/* calendar icon for folders grouping items by date */
+treechildren::-moz-tree-image(title, query, dayContainer) {
+  list-style-image: url("chrome://browser/skin/places/calendar.png");
+}
+

this appear like a dupe(?)

Comment 33

[mcdavis941 (sporadically reading bugmail)]

Attachment: browser.css and places.css v5

fixed

Comment 34

[Damon Sicore (:damons)]

Comment on attachment 317631 [details] [diff] [review]
browser.css and places.css v5

re-request approval once ui review has been completed.

Comment 35

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

Comment on attachment 317631 [details] [diff] [review]
browser.css and places.css v5

uir+a=beltzner

Comment 36

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/themes/gnomestripe/browser/browser.css 	1.215
mozilla/browser/themes/gnomestripe/browser/places/places.css 	1.33
mozilla/browser/themes/winstripe/browser/browser.css 	1.216
mozilla/browser/themes/winstripe/browser/places/places.css 	1.25 

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 02/17 - 02/21)]

Verified with

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050506 Minefield/3.0pre ID:2008050506

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050504 Minefield/3.0pre