From Bug Helper: User-Agent: Mozilla/4.61 [en] (X11; I; Linux 2.2.12-20 i686) BuildID: M13 Windows and Linux both handle the resizable=no arguement of window.open differently, but they both handle it incorrectly. WINDOWS: Doesn't allow the window to be resized by dragging, but still allows for maximizing LINUX: Lets the user resize both by maximizing and window dragging Reproducible: Always Steps to Reproduce: 1.Open the test case I'm submitting 2.type in no in the resizable box 3.click Go Actual Results: On Windows Platforms, Mozilla will let the user resize the form by using the maximize button. On Linux, the user will be able to resize both by maximizing and window dragging. Expected Results: I would expect the same result as you would get on Netscape 4.7 (Windows). In this case, the maximize button is disabled. In addition, the user can't resize by dragging. Navigator 4.7 on Linux is broken also. It allows for resizing like Mozilla does today. I searched on "resizable" on the buzilla helper and didn't find anything. Hope this isn't a dupe...
Confirmed, reassign to vidur.
Assignee: cbegle → vidur
Status: UNCONFIRMED → NEW
Component: Browser-General → DOM Level 0
Ever confirmed: true
QA Contact: asadotzler → desale
Passing window.open() issues off to danm.
Assignee: vidur → danm
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
Nominating nsbeta2. We have to start drawing a line on DOM0 backward compatibility; these bugs are supposed to be a high priority for nsbeta2 per the beta2 criteria.
Keywords: 4xp, nsbeta2
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Setting to [nsbeta3+]. M18.
Target Milestone: M21 → M18
[nsbeta2-], nominating for nsbeta3
Whiteboard: [nsbeta3+] → [nsbeta2-]
Now works fine on Windows and Mac. nsbeta3+, lower priority
Priority: P3 → P4
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Eric, please note that we are not committing to fix lower-priority bugs like this, just P1-P3.
Understood. If windows intended to be non-resizable are resizable for RTM, that's unfortunate, but it doesn't prevent usage of the window, so it could be Futured if necessary.
PDT downloading this bug to [nsbeta2-]. Not critical to PR3 or RTM.
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-][minus]
Marking Future. We should try to do this for the first post-RTM release.
Target Milestone: M18 → Future
I have to disagree a little bit with the priority of this bug on Linux. I have no problem with non-resizable windows being able to be resized as a known issue but what we have now is not cool. 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). 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. I'll attach a screenshot of what I'm talking about in a few minutes. David
djoham, you've raised an excellent point, but it's a distinct issue (pseudo-hanging on Linux only, as opposed to the xp behavior of non-resizable window support not being implemented). Could you please open a separate bug report to track the Linux issue, something like "non-resizable windows appear hung when resized on Linux", so we can track and prioritize that problem independently? Thanks!
done and done. Bug 55913 David
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla0.6
Linux issue was moved to another bug. Windows issue (resizable=no windows can still be maximized) was fixed a while ago. Closing.
You need to log in before you can comment on or make changes to this bug.