Closed Bug 94755 Opened 20 years ago Closed 20 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: 20 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.