467601 - long bookmark names (page titles) will hide tagging icon and tags' text in location bar dropdown list (overlaps, covers up)

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Tony Chung [:tchung]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081201 Minefield/3.1b3pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081201 Minefield/3.1b3pre

In the awesomebar, if the bookmark has a super long description, (eg. www.cnbc.com), then the tag you mark in the bookmark will not be shown when retrieving it later on awesomebar.

See screenshot

Reproducible: Always

Steps to Reproduce:
1. bookmark a webpage with a long bookmark description (exceeds the urlbar space)
2. tag it
3. open a new tab, and type in your tag
4. Verify the long description will overwrite where the tag should have been.
Actual Results:  
Long description overwrites the tag on the awesomebar

Expected Results:  
long description should be clipped with trailing periods, and still show the tag in the right side

Comment 1

[Tony Chung [:tchung]]

Attachment: Long description screenshot

Comment 2

[Dietrich Ayala (:dietrich)]

Not a blocker, but definitely wanted.

Comment 3

[Michael]

Bump

Comment 4

[Dietrich Ayala (:dietrich)]

would definitely take a low-risk patch for this...

Comment 5

[Michael]

Has this been fixed yet?

Comment 6

[Drew Willcoxon :adw]

I started to work on this, but we should clarify what the expected results should be.  It's easy if there's only one or two short tags: just give the tags all the room they need and truncate the title.  But what if there are 20 tags?  How should the space between the two be divvied up?  The current implementation gives the title all the space it needs and only if there's room left over does it show the tags, or a portion of them.

Comment 8

[juan becerra [:juanb]]

I saw this problem in 3.0.x; but I duped 434951 as this one now has traction.

Comment 9

[David Dahl :ddahl]

drew:

I wouldn't worry so much about having 20 tags - or 10 for that matter. Don't let that shape your solution.

Comment 11

[Tracy Walker [:tracy]]

If there is space conflict, perhaps, show just the tags that match search terms?  (that might not be a bad idea in general, rather than showing all tags for matched bookmark)

removing in-litmus? until this is resolved, feel free to add it back at that
time.

Comment 12

[Thomas D. (:thomas8)]

Correcting summary to eliminate the term "description", as that is another property of bookmarks which is not what this bug refers to.

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1

Pretty simple patch. Also now not setting the flex property/attribute of the box that holds the tags, as its unneeded now.

As per comment 9, this does *not* take into account the possibility of a large number of tags.

Comment 14

[Dietrich Ayala (:dietrich)]

Comment on attachment 400320 [details] [diff] [review]
Patch v1

i'm not a Toolkit peer, just Places sub-module owner. you need a toolkit peer or module owner. neil, gavin or mconnor are likely the best options for this patch.

Comment 15

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/689472a1d9a8

Comment 16

[Dão Gottwald [:dao]]

Attachment: broken keyword search colon

Blair, do you see an easy way to fix this or should I back out?

Comment 17

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #16)
> Created an attachment (id=404246) [details]
> broken keyword search colon
> 
> Blair, do you see an easy way to fix this or should I back out?

Bleh. Thankfully, its just a cosmetic regression. Filed bug 520441.

Comment 18

[Tracy Walker [:tracy]]

verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre

Comment 19

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

Comment on attachment 400320 [details] [diff] [review]
Patch v1

approval1.9.2 requests aren't currently being monitored, since we're nearing RC freeze and there are too many outstanding requests, so I'm clearing this request. Feel free to re-request approval if you are confident that it's worth drivers' time to consider whether this non-blocker needs to land for 1.9.2 at this stage.