Closed Bug 435231 Opened 16 years ago Closed 16 years ago

Search makes FF 3 too wide, scrollbar lost

Categories

(Toolkit :: Find Toolbar, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: zaitcev, Assigned: kliu)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9pre) Gecko/2008051913 Fedora/3.0-0.63.cvs20080516.fc10 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9pre) Gecko/2008051913 Fedora/3.0-0.63.cvs20080516.fc10 Minefield/3.0pre

Vertical scrollbar disappears if search function is used and it wraps
or posts other long message. Please see attached screenshot.

Reproducible: Always

Steps to Reproduce:
1. Run Firefox 3 in an unmaximized window (not too wide).
3. Find a page with enough text for scrollbar to appear
   (e.g. a Bugzilla page)
4. Hit ^F, get search bar.
5. Search for any string that is present in the text, like "firefox"
6. Once the text message appears, scrollbar disappears.
Actual Results:  
No scroollbar.

Expected Results:  
Scrollbar present at all times.

This bug has appeared briefly before at this release from Fedora Rawhide
(it tracked Minefield at the time):
firefox-3.0-0.beta2.11.nightly20080115.fc9

You cannot see it if your browser is maximized, and thus the text
produced by the search fits within the existing bar.
Fedora bug (not much extra information there, just for reference):
 https://bugzilla.redhat.com/show_bug.cgi?id=429490
This was supposed to have been fixed by bug 312247.  But the fix for that bug caused problems with the find bar in bug 412646.  The workaround fix for bug 412646 may have regressed the fix in bug 312247, which would be consistent with what you reported in your Fedora bug.  But I don't see this regression in Windows, and the stuff involved here shouldn't be platform-specific.  See bug 412646 comment 21.

I wonder if what was removed by bug 412646 comment 15 caused the regression.
Blocks: 412646
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Various people commented in https://bugzilla.redhat.com/show_bug.cgi?id=429490 that they also couldn't reproduce it on linux.
Pete, you mentioned that you have Flashblock installed. What happens when you disable Flashblock? Or maybe it is caused by one of the other extensions that you might have installed?
When does Fedora pull the source for the builds?  The Fedora bug report was for the 0115 build.  The first WFM was also for the 0115 build.  Bug 312247 landed on 0115, so it's unclear whether those builds were before or after the landing of bug 312247.  The second WFM did not specify the build date, but it sounded like a later build was used.  All of those reports pre-date bug 412646.

Pete, could you add the following to your userChrome.css?

#FindToolbar {
  overflow-x: hidden !important;
}

...and see if that fixes the problem?
Regarding comment #4, the bug occurs without extensions too.

Adding userChrome.css fixes the problem:

[zaitcev@niphredil q0cfinem.default]$ cat chrome/userChrome.css 
#FindToolbar {
  overflow-x: hidden !important;
}
[zaitcev@niphredil q0cfinem.default]$ 
...and it seems that adding that to userChrome.css regresses bug 412646.  Great.

1) I think that the overflow-x: hidden should not have been removed.  While the removal of the align="center" fixes bug 312247 for the find bar on my Windows build, it apparently does not do so in all cases (hence this bug).  It's also unclear why or how removing align="center" would fix bug 312247, so I think that overflow-x: hidden should probably be re-instated.

2) What made Martijn's bug 412646 workaround work was moving the borders from findbar to .findbar-container.  But with overflow-x: hidden removed, that was no longer necessary, which I suppose is why Gavin asked that the borders not be moved.  But if the overflow-x: hidden is to be re-instated, then the borders will need to be moved.


This patch should be tested to make sure that it regresses neither bug 412646 nor bug 312247.  I've tested it on Windows, but I don't have a Mac, and my Linux VPC is too out-of-date to run Firefox 3.
Assignee: nobody → kliu
Status: NEW → ASSIGNED
Attachment #322205 - Flags: review?(gavin.sharp)
Flags: wanted1.9.0.x?
Wait a minute, can this bug be reproduced then, since this is still worksforme.
(In reply to comment #8)
> Wait a minute, can this bug be reproduced then, since this is still worksforme.
> 

It's WFM on Windows too.  But because it's unclear how or why the removal of align="center" could have possibly fixed bug 312247 (it doesn't make any sense why that would have had any effect), I think that we may have been relying on quirky behavior with the align="center" thing, and I am personally inclined to give Pete the benefit of the doubt, especially since adding overflow: hidden reportedly fixes the problem.
The patch in bug 412646 did not only remove align="center", it added a xul:hbox with flex=1 and align="center".
I don't know why that fixed bug 312247, but I think the same goes for overflow: hidden.

Can somebody else on Linux reproduce this bug? On Mac?
(In reply to comment #10)
> The patch in bug 412646 did not only remove align="center", it added a xul:hbox
> with flex=1 and align="center".
>
It was the align="center".  I downloaded a build from before bug 312247's landing and tried removing align="center" without adding the extra hbox.  That fixed bug 312247.  I then tried added the extra hbox without removing the align="center", and bug 312247 persisted.

> but I think the same goes for overflow: hidden.
> 
True, but I think that make a little more sense than align="center".  CC'ing Dao to see what he thinks since overflow: hidden was his idea.

> Can somebody else on Linux reproduce this bug? On Mac?
> 
Yea, let's flag qawanted
Keywords: qawanted
So far I haven't managed to reproduce this on Fedora 7 (tested on two machines,
x86 and x86_64).
WFM, I did not see the bug either using x86 ubuntu 8.4 running minefield 2008052004.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
No longer blocks: 412646
Keywords: qawanted, regression
I'm not sure if this is a duplicate, worksforme, invalid or incomplete...
In any case, this bug doesn't make much sense right now. If anyone can confirm that there's a regression, please reopen.
Attachment #322205 - Flags: review?(gavin.sharp)
Pete, do you see this with the builds at http://www.mozilla.com/en-US/firefox/all-rc.html ?
Flags: wanted1.9.0.x?
Surprisingly, no. The Mozilla's build works fine. Here's the ID:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

I removed the userChrome.css file before testing.
Resolution: DUPLICATE → INVALID
So what's different between the Fedora build and the official Mozilla build?  Do you know what Fedora-specific patches are in that build?  Was that a 64-bit build?


I'm still uncomfortable with how the removal of align="center" could have fixed the problem...
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: