Closed Bug 1040923 Opened 10 years ago Closed 9 years ago

Implement updated styling to Awesome Bar

Categories

(Firefox :: Address Bar, defect)

33 Branch
defect
Not set
normal
Points:
8

Tracking

()

RESOLVED DUPLICATE of bug 1181078

People

(Reporter: sevaan, Unassigned)

References

Details

Attachments

(5 files, 2 obsolete files)

This bug is for the implementation of the visual improvements to the Awesome Bar handled in Bug 1034542. Mockups:http://people.mozilla.org/~sfranks/AwesomeBar/Visual%20Improvements%20to%20Awesome%20Bar.pdf
Flags: firefox-backlog+
Hardware: x86 → All
Depends on: 1034542
Blocks: 1041736
No longer blocks: 1041736
Blocks: 1041736
Points: --- → 8
QA Whiteboard: [qa+]
QA Whiteboard: [qa+]
Flags: qe-verify+
I wanted to work on this bug. In the pdf I really like the changes slide where you explicitly state what should be changed. However, I have a couple of questions: 1. Should the changes be consistent among all the operating systems? 2. I've noticed the sample windows styling (after) has the bookmark star not shrunk. Was that on purpose? 3. What should happen if first/second line is too long to display? Keep in mind what alexbardas says about the ellipsis bug 1040725 comment 11. 4. Any specification for last visited? It looks like the algorithm you proposed is like this: a) if today then "today at time" b) if yesterday then "yesterday" c) if <week then "count days ago" d) if <month then "count weeks ago" e) if <year then "count months ago" f) else "count years ago" Do you want any more for today? Like "just now" or "10 minutes ago"? I think we don't have such functionality right now so we need to specify it.
Assignee: nobody → tkolodziejski
Status: NEW → ASSIGNED
Flags: needinfo?(sfranks)
In point 4 above I just realized that yesterday/today are a little bit different than "x ago" (it's not relative). So I'm not sure we want to treat them as proposed. If you searched sth 20 minutes ago and it's 10 minutes past midnight you'll get "yesterday" which will be so much different from searches you are doing now "today at 0:10". It's also timezone dependent which is, however, not such a big deal.
Blocks: 1040725
We also unnecessarily reserve the space for bookmark star icon.
I'm seeing some code in autocomplete.xml (look for "type == "keyword"") that suggests that we're showing something some visual feedback for keywords. I tried a couple of times but I don't see this code in action at all. I think it's a good bug to address this as well. It's for me a little confusing that in the code it looks like tag and keyword are mutually exclusive but in the UI they are not.
For the keyword case: we're showing magnifying glass for the bookmark with keyword only if there is a %s in the url, which actually makes sense.
QA Contact: andrei.vaida
Hi Tomasz, That's great you want to take this on! My styling is a little out-dated. In Bug 1041736 :mmaslaney gave the design some visual polish, and he includes information on Windows styling, so please look at that stuff, and not what's in my PDF. http://people.mozilla.org/~mmaslaney/Search/AwesomeBar-Spec.png So that should answer questions 1 & 2. Regarding 3, I think it should trail off into ellipses. I'm not sure I understand comment 11 in that bug you linked to. Can you resummarize? 4: How do you feel about keeping the Today at X:XXam/pm, but if the site you visited was within the last hour, then it says X minutes ago?...so up to 59 min ago, and then it switches to the Today (or Yesterday) at Time.
Flags: needinfo?(sfranks)
To be honest I didn't expect so many changes of behavior in this bug. With the updated design it looks like there are a lot and judging from bug 951624 there's not even a slightest chance we can do it in one bug. So my guess is that we can here do the points listed in the pdf but to comply with the png spec, that is just do the visual changes plus introduce "last visited" text. Otherwise, we have a ton of questions that need to be asked and the bug should be split into small ones. 1. Nit: what about transparency/rounded corners as in pdf? *. It looks like the behavior on the image is completely different from what we see today. To summarize: 2. By default we want to show in the location bar: magnifying glass, search engine name (please keep in mind that "(search engine name) Search for:" may not always make sense. I think "Wikipedia Search for:" pretty much does not). Is that correct? 3. What is "Hide search suggestions"? Is it exactly the same button as in "Manage search engines -> Show Search Suggestions"? 4. What happens to the location bar when we focus some history result? 5. How do we comply with what's being done in bug 951624? 5. As far as I know there are no search suggestions in the Awesome Bar right now. Is it discussed anywhere? For example: how do we fit the suggestions in one line? (see suggestions for "what is the name") How am I supposed to choose the suggestion I want? Tab into that line and then use right/left arrow? Sounds very inefficient.
Flags: needinfo?(sfranks)
I spoke with Tomasz, and clarified that this bug is only about the styling, and not any of the added functionality (suggestions, first result item, "last visited").
Flags: needinfo?(sfranks)
Proposed behavior for the first line text overflow. There's a favicon on the left, title text in the middle (which is being cropped if there is not enough space) and optional star on the right. It basically only moves the star to the left but and does the cropping using css-only, yay! Also I don't reserve any space for the star like in my previous screenshot. Can you please have a look if it's the behavior we want?
Flags: needinfo?(sfranks)
Confirmed! The demo worked great.
Flags: needinfo?(sfranks)
Iteration: --- → 35.1
Attached patch updated-awesomebar-simpler.patch (obsolete) — Splinter Review
I'm sorry for not asking on IRC before actually bothering you with feedback? :paolo. It looks like you know a lot about this code. Can you have a look? I've been playing with moving this code to html because it has free overflow support. However, I'm not entirely sure if that's the optimal solution. So moving to html/flexbox gets rid of the js ellipsis (see the demo previous attachment 8480906 [details]). But on the other hand we have to explicitly know the width of the popup and set it using js because otherwise the outer xul box container will increase its length enough to fit the whole text and the ellipsis won't show up. This is problematic because I don't know how to detect the resize of that panel (it would be a bad idea to listen to window resize). I'll be happy to see your feedback and advice whether this makes any sense or should I stick to the ellipsis hack.
Attachment #8484601 - Flags: feedback?(paolo.mozmail)
Attached patch updated-awesomebar-xul.patch (obsolete) — Splinter Review
It isn't working yet but I'm updating the patch with my today's work. The first row is pretty much working: try having too long title or too long search term. I'm very satisfied with the overflow working with css ellipsis. The only hack here is to set fixed width on the outer html container (_setupWidth in the code). I expect that the whole mock can be implemented with this simple concept and some enabling/disabling of boxes (_urlBox, _actionBox in the code. I'm going to add _tagsBox). Flexbox behaves very well when I just hide some of its children. I hope it's ok for me to use html and its mighty flexbox.
Attachment #8484601 - Attachment is obsolete: true
Attachment #8484601 - Flags: feedback?(paolo.mozmail)
Attachment #8485323 - Flags: feedback?(paolo.mozmail)
Comment on attachment 8485323 [details] [diff] [review] updated-awesomebar-xul.patch (In reply to Tomasz Kołodziejski [:tomasz] from comment #12) > :paolo. It looks like you know a lot about this code. Can you have a look? Hi Tomasz, sorry for the late response - the work week kept me quite busy! I wasn't involved in writing this code, but I'll be glad to provide feedback and help answer any questions around it when I can. > I've been playing with moving this code to html because it has free overflow > support. However, I'm not entirely sure if that's the optimal solution. I guess the reason for manual overflow handling wasn't the lack of support in XUL (if I remember correctly, XUL labels can be configured to handle overflow automatically), but to show or hide the tooltip displayed when hovering the cursor over the truncated text. This would mean that changing these elements to use HTML wouldn't provide much value by itself. > But on the other hand we have to explicitly > know the width of the popup and set it using js because otherwise the outer > xul box container will increase its length enough to fit the whole text and > the ellipsis won't show up. This, and the fact that we may have to debug and ensure the accessibility, keyboard navigation, and right-to-left localization properties of the new HTML elements don't regress compared to the current XUL behavior, make me think that we should stick to the existing approach.
Attachment #8485323 - Flags: feedback?(paolo.mozmail)
I've heard that the reason is that when this code was written there was no CSS ellipsis. What's more, support for XUL is really weak. It only works for labels as you said but we have "html labels" that is "this is <span>highlighted</span> text". XUL does not support that. I talked to :adw and it looks like accessibility is the biggest deal. right-to-left support is built into flexbox so that would work (I'd be more concerned with current ellipsis in rtl but since it's there for a long time it surely works). I'll try to implement these changes with minimal impact using XUL.
Hey Sevaan, I need updated icons: tag (chrome://browser/skin/places/tag.png) and switch-to-tab (chrome://browser/skin/actionicon-tab.png) and possibly favicon (chrome://browser/skin/places/star-icons.png). I need them in both normal and high-dpi. Also, the png above is missing the keyword search look. If you want to change it (or change the magnifying glass icon) then I'd need that as well.
Flags: needinfo?(sfranks)
Attaching the updated Awesome Bar visual spec by mmaslaney.
(In reply to Tomasz Kołodziejski [:tomasz] from comment #16) > Hey Sevaan, I need updated icons: tag (chrome://browser/skin/places/tag.png) > and switch-to-tab (chrome://browser/skin/actionicon-tab.png) and possibly > favicon (chrome://browser/skin/places/star-icons.png). I need them in both > normal and high-dpi. > > Also, the png above is missing the keyword search look. If you want to > change it (or change the magnifying glass icon) then I'd need that as well. Mike, do you have these assets?
Flags: needinfo?(mmaslaney)
Tomasz, would you like the assets in png or svg format?
Flags: needinfo?(mmaslaney) → needinfo?(tkolodziejski)
Svg is fine.
Flags: needinfo?(tkolodziejski)
I've been fighting with the XUL. I couldn't accomplish the design as in my HTML mockup anyhow and so I ended up using flexbox nonetheless but this time with XUL. My biggest problem was to have star right after the title text. That's because the js ellipsis works only with flex="1" box which it exactly what I didn't want. Please have a look whether the XUL changes makes sense. I have a question: why it didn't work without the additional <xul:hbox>? (you will notice one hbox that I added just because it worked with it) Don't pay attention for the color changes in this patch. That part is not ready yet. But the boxes should be in (more or less, not pixel-perfect yet) right places.
Attachment #8485323 - Attachment is obsolete: true
Attachment #8486128 - Flags: feedback?(paolo.mozmail)
Comment on attachment 8486128 [details] [diff] [review] updated-awesomebar-xul.patch Hi Tomasz, I haven't really worked with XUL in the past few months, I could definitely review this but it would still take quite some time. Jared, maybe you can answer Tomasz questions on the XUL code better than me?
Attachment #8486128 - Flags: feedback?(paolo.mozmail) → feedback?(jaws)
Flags: needinfo?(sfranks)
Attachment #8486128 - Flags: feedback?(jaws) → feedback?(dao)
Iteration: 35.1 → 35.2
Ping dao. I wanted to get back to this bug but I still need some feedback on XUL. What's even worse, as far as I know this got a little outdated now. I also need some help with colors. I discussed it with Alex and it looks like changing colors is not that simple due to themes support (and also high contrast stuff in some old Windows). If you can't give feedback about that dao, please let me know.
Flags: needinfo?(dao)
Comment on attachment 8486128 [details] [diff] [review] updated-awesomebar-xul.patch > <binding id="autocomplete-richlistitem" extends="chrome://global/content/bindings/richlistbox.xml#richlistitem"> > <content> >- <xul:hbox align="center" class="ac-title-box"> >- <xul:image xbl:inherits="src=image" class="ac-site-icon"/> >- <xul:hbox anonid="title-box" class="ac-title" flex="1" >- onunderflow="_doUnderflow('_title');" >- onoverflow="_doOverflow('_title');"> >- <xul:description anonid="title" class="ac-normal-text ac-comment" xbl:inherits="selected"/> >+ <xul:hbox align="center" class="ac-title-box" style="display:flex"> >+ <xul:image xbl:inherits="src=image" class="ac-site-icon" style="flex-shrink:0"/> >+ <xul:hbox> >+ <xul:hbox anonid="title-box" class="ac-title" >+ onunderflow="_doUnderflow('_title');" >+ onoverflow="_doOverflow('_title');"> Looks like you're mixing flexbox and XUL layout here, which seems extraordinarily brittle, because there's no spec defining how these things should interact. I would strongly advice against doing this and I can't really answer questions about why this layout mix behaves in certain ways that you didn't intend. I would also recommend morphing this to a meta bug tracking smaller changes in separate bugs. I don't think it's necessary nor efficient to implement the entire design update in one monolithic patch.
Attachment #8486128 - Flags: feedback?(dao) → feedback-
Flags: needinfo?(dao)
Depends on: 1073243
I'm still waiting for the svg icons mmaslaney. Can you post them here?
Flags: needinfo?(mmaslaney)
Blocks: 1071461
AFAIK the assets are attached in bug 1041736.
Iteration: 35.2 → 35.3
Blocks: 1061755
No longer blocks: 1061755
Blocks: 1079452
Iteration: 35.3 → 36.1
Getting this off of Tom's plate.
Assignee: tkolodziejski → nobody
Status: ASSIGNED → NEW
Iteration: 36.1 → ---
Depends on: 1074937
No longer depends on: 1074937
Depends on: 1181078
This has been superseded by bug 1181078, so I'm closing it. In case we can still recover resources from here.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: