Closed Bug 83220 Opened 24 years ago Closed 24 years ago

MFCEmbed "flashes" between page loads

Categories

(Core :: DOM: Navigation, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla0.9.2

People

(Reporter: hyatt, Assigned: hyatt)

References

Details

(Whiteboard: have r=, sr=, a=)

Attachments

(1 file)

I discovered that I caused this, and I have a patch that fixes it. It's trivial. I just need to move the CheckForFocus call out of InitialReflow and into the paint unsuppression routine. This will also address jgaunt's hidden window issues, since by the time I do the check now, the widget will have been shown.
Ok, I have r=saari, I just need an sr.
Status: NEW → ASSIGNED
Targeting at 0.9.1. This is a very obvious visual defect whose fix is safe and trivial.
Target Milestone: --- → mozilla0.9.1
OS: Windows 2000 → All
patch?
does it show up in builds that some of our embedding friends make?
the summary reflected that this shows up in mfcEmbed. Hard to tell if it shows up in embedding builds besides mfcEmbed since we are lacking builds at this point.
QA Contact: adamlock → bmartin
Hyatt showed me on his machine his change to fix this moving one line from one of a pair of routines always called together to the other. We discussed, and he avered that in no situation could the moved function call somehow be missed in this new pattern. He couldn't attach a patch at that moment because of other changes in his tree. He _will_ attach a patch, however, moving that one line, and fixing a old-style cast nearby. When he does, that patch is sr=scc.
Blocks: 81668
I'm sure this would show up in any Windows embedding client.
a= asa@mozilla.org for checkin to 0.9.1
Whiteboard: have r=, sr=, a=
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: