Closed
Bug 100406
Opened 23 years ago
Closed 15 years ago
centerWindowOnScreen doesn't for helper dialog
Categories
(Core Graveyard :: File Handling, defect)
Core Graveyard
File Handling
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: rockowallaby, Unassigned)
References
Details
Attachments
(2 files)
(deleted),
patch
|
law
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
These two windows always seem to appear slightly offscreen on my system (at
1024*768 too!), causing me to have to move the window so I can click on OK or to
see the full progress. I've tried moving the window hoping Mozilla might save
it, but to no avail.
Comment 1•23 years ago
|
||
The reason this is happening is because in nsHelperAppDlg.js, this line isn't
working:
http://lxr.mozilla.org/seamonkey/source/embedding/components/ui/helperAppDlg/nsHelperAppDlg.js#228
The reason this happens is because centerWindowOnScreen doesn't work properly
unless sizeToContent has been called.
The fix is to call this.mDialog.sizeToContent() before calling centerWindowOnScreen.
maybe we should add sizeToContent into the actual centerWindowOnScreen call in
dialogoverlay.js?
Copying Bill Law because he wrote this code originally
Not sure of a component, so putting to browser general for classification.
Assignee: mpt → asa
Status: UNCONFIRMED → NEW
Component: User Interface Design → Browser-General
Ever confirmed: true
OS: OS/2 → All
QA Contact: zach → doronr
Hardware: PC → All
Summary: OS/2 - Window positions of 'What should Mozilla do with this file?' and the file download progress window → centerWindowOnScreen doesn't for helper dialog
Comment 2•23 years ago
|
||
->XP Apps.
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Updated•23 years ago
|
Component: XP Apps → File Handling
Comment 3•23 years ago
|
||
Bill,
As long as you are messing with these dialogs, you could fix this :)
Mike, your "fix" doesn't seem to work for me. Did you try that on Win32?
The download dialog doesn't come up offscreen for me. It definitely isn't
centered on the screen (it's a little too low and to the right) but not off the
screen. It comes up in the same place with your fix.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 6•23 years ago
|
||
Comment 7•23 years ago
|
||
I attached on actual patch.
I just tested and this did work for me on Win32 - dialog is now centered instead
of down and to the left.
What I don't understand is why it was only offscreen on OS/2 in the first place.
Your patch is the same as what I had tried.
When you say "this did work for me on Win32" do you mean *before* the patch?
In other words, the problem is OS/2 only? That could be due to subtle timing
differences in the way the window messages come in.
Since the patch doesn't do any harm on other platforms, I guess we can add the
code to fix OS/2.
Comment 9•23 years ago
|
||
The download windows does NOT come up centered on Windows it comes up slightly
down and to the right.
This patch makes it come up exactly centered. I tested this.
On OS/2, it comes up way to the right.
It's a little subtle - maybe it depends on the resolution, but the Windows
dialog is definitely not centered.
Comment 10•23 years ago
|
||
Comment on attachment 56550 [details] [diff] [review]
Fix that worked for me on Win32
r=law
Dialog still off slightly in at least one situation on Win32, but patch fixes at least one Win32 case and the worse problem on OS/2.
Attachment #56550 -
Flags: review+
Comment 11•23 years ago
|
||
sr=hyatt
Comment 12•23 years ago
|
||
Fixed. Dave Hyatt and I talked and we concluded that this still might not work
in all cases because the icon image that gets inserted will change the content
further. Probably my testcase used a different mime type with a different
handler with a different icon.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 13•23 years ago
|
||
helper app dialog now pops up centered on the screen. the thing is --if i move
the dialog to another position on the screen [to get it a bit out of the way of
other windows], that new position is not remembered...
i'd think that the first time [in a given session for a give profile, perhaps?]
the dlg is opened, it's okay to center it. but if the user moves it, the app
should respect that decision. i believe that had been implemented some time ago
--should i open another bug for this aspect, or reopen this one?
tested using 2001.11.08.0x commercial builds on all platforms.
Comment 14•23 years ago
|
||
Can you verify on an earlier build that the position of this dialog was saved?
I don't think it was.
Reporter | ||
Comment 15•23 years ago
|
||
I'm on build 20011109 (OS/2) and while the 'What should I do with this file?'
dialog appears centered, the download progress dialog seems just slightly (about
one window-control width) offscreen, down and to the right. Was this supposed
to be fixed here or should I submit another bug?
Comment 16•23 years ago
|
||
the oldest build have on my boxes is 6.1rtm, from late july 2001...it doesn't
show the 'saved position' state i mentioned in comment #13. hrmm.
danm, shouldn't dlg positions --when moved by use-- be remembered? or, has that
regressed? would that be covered by bug 101579, bug 41202, or another bug?
Comment 17•23 years ago
|
||
Currently I think the "center" directive gets precedence over "restore last
position." You're right; that should probably just be reversed.
Reporter | ||
Comment 18•23 years ago
|
||
OK, the helper dialog is centered fine, but I still see that the 'Downloading
file' window is still not centered, and depending on your font size it may be
slightly off screen or even clips some of the buttons (but not severely).
Should I make a new bug concerning JUST the 'Downloading File' dialog?
Comment 19•23 years ago
|
||
I suspect you're seeing some complication from the fact that we substantially
alter that dialog's content as it comes up. This could throw off the
auto-sizing. Please open another bug on that. There may still be one
outstanding, in which case we'll eventually find one of them and make it a dup.
We've tried various tricks along the way to overcome this problem and I don't
know if those fixes were good enough to dispose of the bug.
Comment 20•23 years ago
|
||
As Bill mentioned, the part where the contents of a dialog are modified in its
onload handler makes sizing and centering difficult. Still, I feel I should
push the built-in positioning capabilities which I think work better than the
scripted ones. The above patch fixes the progress dialog centering problem for
me.
Comment 21•23 years ago
|
||
OK, since Dan has given us the fix (thanks), I'll reopen and land this when I
get to it (soon).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Comment 22•23 years ago
|
||
Spam: Dropping off my list for MachV/mozilla1.0. If you have issues, please
make your case by stating which of my mozilla0.9.9 or mozilla1.0 bugs you think
are of lesser importance.
Please note that *some* of these might be fixed elsewhere if there is work
being done in the same area of code. In most of those cases, I will have
marked such bugs by putting the *real* bug in the "depends on" field.
Keywords: helpwanted
Target Milestone: mozilla0.9.9 → Future
Updated•22 years ago
|
QA Contact: sairuh → petersen
Updated•15 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Comment 23•15 years ago
|
||
Non-Centered dialog boxes have the advantage to not overlay each other as Enigmail boxes sometimes do. Wontfix.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 15 years ago
Keywords: helpwanted
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•