Closed Bug 365175 Opened 18 years ago Closed 18 years ago

background-position of background-image not restored/recalulated after viewport resize

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: marc.bau, Assigned: dbaron)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Layout destroyed Reproducible: Always Steps to Reproduce: 1. open the page for e.g. with a viewport of 1024x768 2. put your eyes on the navigation menu (left) and see the space between the Menu Items and the + Squares 3. now resize the browser viewport to - lets say - 800x600 or better less width! 4. you can see the squares are squeezed with the Menu Item - ok - no problem. 5. now maximize your browser back to 1024x768 6. the squares "background-position" is not recalculated 7. reload the page - site looks ok. Actual Results: menu squares looks very bad. IE and all other browsers are ok, FF not. Expected Results: correctly recalculated "background-position"
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Moving to CSS and confirming, I also see then on WinXP FF 2.0.0.1. Reporter, could you provide a minimal testcase attachment? Robin
Assignee: nobody → dbaron
Status: UNCONFIRMED → NEW
Component: General → Style System (CSS)
Ever confirmed: true
QA Contact: general → ian
So.. this bug has "trunk" as the version, but was filed with a branch build and worse yet confirmed with a branch build. It's been fixed on trunk ever since the reflow branch landed (almost 3 weeks before the bug got filed). We do need a testcase to add to the regression suite, though.
Status: NEW → RESOLVED
Closed: 18 years ago
Depends on: reflow-refactor
Flags: in-testsuite?
Resolution: --- → FIXED
i can confirm this bug exists in FX 2.0.0.3, too. What does Trunk means? Will this become fixed in 2.0.0.4 or in 3.x?
It means this bug specifically regressed due to a checkin which exists only on the trunk, which is the code tree which will become Firefox 3.0. If you think you're seeing this bug or one like it with a 2.0 build, please file a new bug.
Sorry, stupid moment. This bug was fixed on the trunk, which as bz said will be Firefox 3.x. Disregard the last comment. Sorry for the spam.
Ryan, sorry but i filed this bug against 2.x and not a 3.x trunk. Now i should open an additional bug for 2.x - that sounds very strange :-(. I don't know how difficult it is to fix this bug, but it should be fixed in 2.x, too. 3.x is far far away...
Like I said, I completely misspoke in comment #5. Completely disregard it. Don't do anything besides waiting for Firefox 3 :)
So i reopen this case now and change the branch back to the correct 1.8 version to hopefully get this fixed in the next 2.0.0.4
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Version: Trunk → 1.8 Branch
It's not going to happen. The 2.x branch is really only open for security, stability, and regression fixes at this point. Especially for a reflow bug like this which is fixed on the trunk (by a landing which took roughly two years to develop), developers aren't going to attempt to fix this for 2.x.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Version: 1.8 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.