Closed Bug 94755 Opened 23 years ago Closed 23 years ago

Sizing problem on persistent xul window

Categories

(Core :: XUL, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 90276

People

(Reporter: rangansen, Assigned: danm.moz)

Details

I observed that for xul windows with persistent height/width as well as dynamic resizing to fit in all the components, the persistent values [from localstore.rdf] tend to override the dynamic values - even when the persistent size is smaller that the dynamic size - thus sometimes chopping off part of the window. I found this while working on some xul sizing problems in psm. They are pretty consistent for resizable window, but somewhat intermittent for non-resizable ones. For Example: I have a window for which height and width are persistent, and the window is wrongly sized - it is too small to fit all the elements. I add dynamic resizing to take care of the problem What is expected: The larger one between the dynamic and the persistent size[from the localstore.rdf] should take effect. What happens: The persistent size overrides - even when the dynamic size is larger. What it implies : If a window originally had a sizing problem, and it is fixed [say, by adding dynamic resizing], the fix never shows up - user keeps on seeing the old, persistent size as long as he is using the same profile. I believe it is important to fix this issue - for otherwise, many of our window sizing related fixes might not show.
Keywords: nsenterprise
I forgot to mention - even making the window non-persistent does not resolve the problem, because if the same profile is used, based on the localstore.rdf entry, it still thinks the window is persistent, and beheaves the same way.
Bug 95111 is about not applying attributes from localstore if they're no longer specified as persist in xul.
-> danm
Assignee: trudelle → danm
*** This bug has been marked as a duplicate of 90276 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.