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: