Closed Bug 79543 Opened 24 years ago Closed 22 years ago

helper app dialog does not redisplay properly after "Set Default..."

Categories

(Core Graveyard :: File Handling, defect, P2)

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: law, Assigned: law)

References

Details

(Whiteboard: workarond checked in, rendering team looking at)

Attachments

(1 file)

painting problem in download dialog
24.06 KB, image/jpeg
Details 
Steps to reproduce:

1. Click on a link to some non-html, non-text data (e.g., a binary to be
downloaded).
2. Click the "Set Default..." button to open either the "Edit Type" or "New
Type" dialog.
3. Dismiss that dialog.
4. Observe that the helper app dialog contents may have changed bug do not
redisplay properly.  Only the portion of the dialog that was obscured by the
other dialog will be redrawn.  There will be bits and pieces of the "old" dialog
visible (e.g., ghost buttons that don't respond when you click on them).

This could be a xul/xp-toolkit issue.
Nominating.
Keywords: nsbeta1
Blocks: 78106
also see this on linux. attaching screenshot...
OS: Windows 2000 → All
Hardware: PC → All
nav triage team:

Adding hyatt, karnaze, and kmcclusk to cc list. Marking nsbeta1+, p2, and 
mozilla0.9.1

Guys, any ideas why this is happening?
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
Guys, any idea why this is happening?
May be a duplicate of the general refresh problem described in bug 74129. I'm 
looking at that problem now.
Depends on: 74129
74129 morphed in to 80847.  changing depends
Depends on: 80847
No longer depends on: 74129
I checked in a fix for bug 80847 yesterday.
sairuh@netscape.com:  Could you see if this bug still occurs?


nav+pdt triage: sarah, does this still happen? - it needs to be verified
alas, this is still a problem on the three main platforms, with both modern and
classic themes [2001.05.16.12].

in fact, it's even worse with classic --the resulting dialog from click Set
Default also displays paint problems. :-/
We need to get some help on this, need to figure out who's the right person 
for that. 
I'll take a look at this.
Kevin - thanks for taking a look at this. If there is any FE workaround that we 
can implement for m0.9.1, that would be great too.
Whiteboard: rendering team looking at
I can not reproduce the problem in a 2001051704 build on WINNT. I can not
reproduce the problem using a 5/17 Linux build as well.

peterson@netscape.com was not able to reproduce the problem on 5/21 build on WINME.
still a problem on mac, linux and winNT using 2001.05.18.13 comm verif bits.
also still a problem on my linux debug from 13:37 today.
I can reproduce this easily with today's win2k bits. 

The "reason" this happens is the in the onload handler of that dialog, the 
text of the first two messages "You have chosen..." and "What should..." is 
modified to substitute in the URL, mimetype, brandname, etc. 

This "mucks up" [technical term] the calculation of intrinsic sizing. When the 
dialog subsequently gets a reflow (after hitting Cancel after bringing up the 
'Set Default...' dialog) the elements in the UI are reflowed to new locations, 
but not everything is repainted.

There may be a **** FE workaround by setting 'min-height' on the <html> in 
the dialog (although I could only get this to work by setting px, not by em, 
which would be the preferrable way to do this).

Maybe danm has a better recommendation of what to do with a dialog that will
effectively be inserting long strings into a dialog (e.g., the URLs) after the 
dialog has already been sized and displayed.
Here's a cheap, bogo-fix, but maybe it also says something about why this is 
happening (to those who know what is really going on).

Index: nsHelperAppDlg.js
===================================================================
RCS file: 
/cvsroot/mozilla/embedding/components/ui/helperAppDlg/nsHelperAppDlg.js,v
retrieving revision 1.8
diff -u -r1.8 nsHelperAppDlg.js
--- nsHelperAppDlg.js   2001/05/03 23:34:41     1.8
+++ nsHelperAppDlg.js   2001/05/22 03:14:46
@@ -233,6 +233,7 @@
         }
         modified = this.replaceInsert( modified, 2, 
this.mLauncher.MIMEInfo.MIMEType );
         modified = this.replaceInsert( modified, 3, this.mSourcePath );
+        intro.firstChild.nodeValue = "";
         intro.firstChild.nodeValue = modified;
     },



Bill, could we just get this workaround checked in for now? 
I checked in John's suggested workaround (snuck in as part of the fix for bug
68279; so sue me :-).

It seemed to help in my debug build but I still saw flakiness on occasion.  Do
we see sufficient improvement that we can either close this bug or reduce its
priority?
Could you sneak in a comment "// workaround for bug 79543". [Otherwise, that
line will get removed before long.]

If the workaround is good enough, then there are probably bigger fish to 
fry. But, I'd like to keep this bug alive, since it shouldn't be necessary 
to do that hack; there is something wrong with the way that dialog is being
layed out. However, I doubt that a real fix is going to come before rtm.
Sairuh - is this in a sufficiently good state that it can go off the beta 
stopping list. BTW we cannot use helper apps at all today - crashes, are you 
seeing the same?
Whiteboard: rendering team looking at → workarond checked in, rendering team looking at
the workaround seems to work for me --i'm using 2001.05.23.08 moz bits on linux,
and so far don't get a crash using the helper app to download. [unable to check
other platforms at the moment.]
lets check windows and mac, if the workaround works, we can move this bug to 
m0.9.3 at least. 
to confirm, this dialog looks fine [after dismissing the add/new type dialog] on
mac and winnt, with both classic and modern themes [2001.05.24.0x bits]. also
doublechecked both themes on linux [2001.05.23.08], and this is fine.
In light of the workaround doing fine, I'm moving this bug to mozilla1.0.
Target Milestone: mozilla0.9.1 → mozilla1.0
Component: XP Apps → File Handling
->future

Some obscure xul/layout quirk, not worth worrying over right now.
Target Milestone: mozilla1.0 → Future
QA Contact: sairuh → petersen
unable to repro... the "Advanced" button is no longer present (per fix in bug
86640).

reopen if this is still an issue with current builds, but pls provide specific
steps to reproduce this particular bug. mind you, this differs from other bugs:
bug 112180 (pushed downwards) and bug 79889 (clipped on/pushed to the right).
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: