Closed Bug 55913 Opened 24 years ago Closed 24 years ago

non-resizable windows appear hung when resized on Linux

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: djoham, Assigned: danm.moz)

Details

From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (X11; I; Linux 2.2.15-4mdk i686) BuildID: 2000100906 Currently, on Linux if you try to resize a non-resizable window you get what looks like a hung application. The contents of the page remain the same, but the expanded window shows the artifacts of the window resizing animation (if available). Reproducible: Always Steps to Reproduce: 1. go to the URL http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5527 2. open a new window with resizable=no 3. attempt to resize the browser Actual Results: The contents of the window remain the same size, but the artifacts of the window resize animation remain painted, giving the impression of a hung application. Expected Results: I would expect this function to either work 100% or not at all. By not at all, I mean let the user resize the application if they so desire. This bug is related to bug 28621 There is a screenshot of the problem at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=16478 This is really annoying on sites like Microsoft's Outlook web access where they've made their composing window non-resizable. In Mozilla, you need to resize the window in order to see everything. With this problem, you get **** thrown up on the screen the looks *really* bad. I guess I'd really like to place this in the polish category. If we can't make the window non-resizable, then lets just back off and let the user do what they want until the real fix is in.
over to XPApps
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
cannot seem to repro this using commercial branch bits 2000.10.10.10-n6 on redhat 6.2... claudius/jrgm, do either of you see this? if so, could it be a widget issue rather than xp apps?
QA Contact: sairuh → claudius
I don't see this on the 2000101010 branch builds either. When using the testcase page to create a non-resizable window, I was indeed able to resize all I wanted. This may be a recent trunk regression. And yes, I think this is a toolkit thing.
QA Contact: claudius → jrgm
I would agree that if the window is resizeable (because resizeable=no is not working) that the contents should be resized as well. I do see this "no refresh" in the image you supplied. However, I tried the same build with enlightenment and twm (and some other trunk and branch builds to boot) and I can't reproduce this. Could you try this again, perhaps with a different WM and note if that makes a difference for you (which WM works [if any], which doesn't). -> danm/Future.
Assignee: don → danm
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Component: XP Apps → XP Toolkit/Widgets
This is interesting. From everyone's comments, I was assuming it would be a KDE problem. However, I just tried it with KDE and GNOME on a new build and I was able to re-size just fine. I'll try it this weekend with M18. I'll mark fixed if things are OK there. David
Build 2000102315 seems to be OK. Resizing is allowed (bad) but it doesn't look locked up (good). Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.