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.

I can repro Str 1. Open about:support 2. Ctrl+F --- observe background color of findBar 3. Close findBar --- observe background color of findBar

It's really ephemeral to catch! :) http://i.imgur.com/KTpGGZO.png

Wouldn't block 25's release, but worth tracking.

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!

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!

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.

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?

(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.