Closed Bug 891948 Opened 7 years ago Closed 7 years ago

Redesigned Find bar flashes to white while closing.

Categories

(Toolkit :: Find Toolbar, defect)

25 Branch
All
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla26
Tracking Status
firefox24 --- unaffected
firefox25 - affected

People

(Reporter: ferongr, Assigned: mstange)

References

Details

(Keywords: regression, Whiteboard: fixed by bug 893446)

Attachments

(2 files)

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130710 Firefox/25.0 ID:20130710030205 CSet: 04d8c309fe72

STR: Close the Find bar.

Could be platform-specific.
Blocks: 776708
I can repro
Str
1. Open about:support
2. Ctrl+F
   --- observe background color of findBar
3. Close findBar
   --- observe background color of findBar
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: Trunk → 25 Branch
It's really ephemeral to catch! :)
http://i.imgur.com/KTpGGZO.png
Wouldn't block 25's release, but worth tracking.
Assignee: nobody → mdeboer
Keywords: regression
Status: NEW → ASSIGNED
Dão, I flagged you for feedback, because this is my first shot at smoothing the transitions of the findbar and the content below it. I'm using position: fixed for the findbar to place it on top of the content, after which I can transition the content's margin-top. This makes the content not 'bounce down' when the findbar shows and gently animates the content up when the findbar hides.

I hope you like it!
Attachment #776294 - Flags: feedback?(dao)
Just a heads up about attachment 776294 [details] [diff] [review] in comment 4, I once tried the exact same thing with FindBar Tweak, to position:fixed the findbar and use margin-tops to move the content downward. In fact it is still capable of doing just that through some hidden preferences. On longer pages, it took extremely long to open and close the find bar (could be up to five seconds), and that was without animation. Once/if this hits nightly I'll be happy to test using the same pages, I believe I still have them saved in an e-mail a user once sent me when he reported this. Just thought it was worth noting this.
(In reply to Quicksaver from comment #5)
> Just a heads up about attachment 776294 [details] [diff] [review] in comment
> 4, I once tried the exact same thing with FindBar Tweak, to position:fixed
> the findbar and use margin-tops to move the content downward. In fact it is
> still capable of doing just that through some hidden preferences. On longer
> pages, it took extremely long to open and close the find bar (could be up to
> five seconds), and that was without animation. Once/if this hits nightly
> I'll be happy to test using the same pages, I believe I still have them
> saved in an e-mail a user once sent me when he reported this. Just thought
> it was worth noting this.

Could you post the links here? I'd like to test that as well!
Well, this is frustrating. The link I mentioned a user sent me appears to be offline at the moment. It was some sort of russian torrent tracker, I have no idea what it was exactly as I don't speak russian. Here's the link anyway:
http://www.rutracker.ru/stats.php?mode=btu.u_up_total

I was trying to find other examples of long/large pages to test on, but so far only one has triggered a slowdown in my implementation of this kind of method in FBT:
http://www.arngren.net/
I'm not sure if that is because there's a lot of content being rendered that needs to be moved or if that page is just too heavy in general (I don't feel any difference in scrolling for example). This page does, however, slowdown my find bar on top with an implementation similar to your patch, something that does not occur if I keep the find bar at the bottom.

I'm sorry for first alerting to a possible issue and then being unable to follow through properly.
(In reply to Quicksaver from comment #7)
> I was trying to find other examples of long/large pages to test on, but so
> far only one has triggered a slowdown in my implementation of this kind of
> method in FBT:
> http://www.arngren.net/

Tested that one with my implementation and the anim keeps being snappy. What a fantastic example of a horrid site, btw ;)

> I'm sorry for first alerting to a possible issue and then being unable to
> follow through properly.

Don't be, I'm glad you're trying to help out!
Duplicate of this bug: 894608
Comment on attachment 776294 [details] [diff] [review]
Patch v1: fixed findbar positioning to smoothen transitions

>+++ b/browser/themes/linux/browser.css
>+.browserContainer[findbar-top-hidden="false"] > .browserStack {
>+  margin-top: calc(2em + 6px);
Curious, where do these calculations come from?

>+++ b/toolkit/themes/linux/global/findBar.css
>@@ -10,33 +10,39 @@ findbar {
> findbar[position="top"] {
>+  position: fixed;
>+  width: 100%;
These are probably going to cause problems when sidebars on either side appear as the 100% width will cause some side to overflow/get hidden.
Comment on attachment 776294 [details] [diff] [review]
Patch v1: fixed findbar positioning to smoothen transitions

> findbar[position="top"] {
>+  position: fixed;
>+  width: 100%;
>   box-shadow: 0 -1px 1px rgba(0,0,0,.1) inset;
>   transition-property: margin-top, opacity, visibility;
> }
> 
>+findbar[position="top"] > hbox {
>+  width: 100%;
>+}

Unfortunately this makes the find bar too wide, e.g. it makes it overlap things on the content area's right side (e.g. #browser-border-end on Windows) and moves part of the find bar off-screen when opening a side bar on the left side.
Attachment #776294 - Flags: feedback?(dao) → feedback-
Assignee: mdeboer → mstange
No longer blocks: 893446
Depends on: 893446
Whiteboard: fixed by bug 893446
Target Milestone: --- → mozilla26
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
QA Contact: manuela.muntean
While testing for the pre-beta sign-off of the Find Bar Redesign feature, I tried to verify this bug with the latest Aurora (build ID: 20130903004001), and this works as expected on Win 7 64-bit - the redesign bar is smoothly closed.

However, when activating the SocialAPI demo (http://mixedpuppy.github.io/socialapi-demo/) and resizing the window, the Find bar overlaps the SocialAPI top bar. We haven't encounter this behavior for History/Bookmarks left bars.

Considering that this is not tracked for 25 release, I'm assuming that this is the expected behavior, right?
Flags: needinfo?
(In reply to petruta.rasa from comment #13)
> However, when activating the SocialAPI demo
> (http://mixedpuppy.github.io/socialapi-demo/) and resizing the window, the
> Find bar overlaps the SocialAPI top bar. We haven't encounter this behavior
> for History/Bookmarks left bars.
> 
> Considering that this is not tracked for 25 release, I'm assuming that this
> is the expected behavior, right?

That's bug 821687, AIUI.

When you set needinfo?, you need to set it to a specific person - untargeted needinfo requests will just be lost.
Flags: needinfo?
You need to log in before you can comment on or make changes to this bug.