Closed Bug 385704 Opened 13 years ago Closed 4 years ago

Fixed location elements do not re-position themselves when client area size is changed due to the removal of a UI element


(Core :: Layout, defect)

Windows XP
Not set





(Reporter: nicholas, Unassigned)




(Keywords: regression, Whiteboard: DUPEME)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070624 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070624 Minefield/3.0a6pre

When the size of the client area is changed due to the removal of a UI element, such as the tab bar disappearing or the find bar being closed some elements with a fixed position update their position. 

For example; if you have an element with "position: absolute; bottom: 0px;" that object should render at the bottom of the client area.

Reproducible: Always

Steps to Reproduce:
1. Open the above link ( in a new window, notice the footer is correctly positioned at the bottom of the client area.
2. Press "Ctrl + T" to open a blank tab.
3. Press "Ctrl + F" to bring up the find bar.
4. Close the blank tab.
5. Close the find bar by clicking the red "X" on the far left of it.
6. Notice that the vertical position of the footer has not been updated, it is still in the same position as it was when the tab bar and the find bar was open.

Other elements might or might not have updated their size and position.
Actual Results:  
The footer's vertical position is not updated, it remains at the same vertical position as it was located before the find bar and/or tab bar was closed.

Expected Results:  
When the tab bar is closed or the quick find bar is closed the vertical size of the client area increases as a result. 

The fixed position element (the page footer) should have been be repositioned so that it is at the bottom of the page.
I forgot to mention that all elements update their position if the browsing window is resized or a sidebar is opened or closed.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Whiteboard: DUPEME
I don't see this bug on the branch, only on trunk.
Might be useful to find out when this regressed (between 2006-12-07 and 2006-12-08?)
Keywords: regression
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a1

Doesn't work:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1

Due to reflow branch (bug 300030)
Sounds like bug 363707
I'm not convinced that's the same bug. That bug is about a frameset, while this is about a fixed positioned element. I might be wrong though.
Ever confirmed: true
The page is not a frameset, all elements are positioned with CSS but bug 363707 does appear to be related to this bug.

The only difference I find between this bug and bug 363707 is that 363707 correctly redraws when the find bar is closed (but not the tab bar).

In both bugs I've noticed that if you resize the window (making it taller) size of and/or position the elements seem to inconsistently change to match the size of the client area of the window (it doesn't resize / reposition smoothly).

Try making the window it taller not wider with these 2 pages:
You'll notice that the position and size of the elements seems to stay the same and then suddenly "jump" to the correct size and position that they should be.
This works for me on linux trunk nightly 2008-02-10, following the steps to reproduce in comment 0. Is it still an issue for anyone else?
Not reproducible in windows-XP with latest Nightly and release.
Considering this I will mark this issue as Resolved-WORKSFORME. If anyone can still reproduce it, feel free to reopen the issue and provide more information. Thanks

Version 	48.0a1
Build ID 	20160405030214
Update Channel 	nightly
User Agent 	Mozilla/5.0 (Windows NT 5.1; rv:48.0) Gecko/20100101 Firefox/48.0
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.