51904 - The contents under Preferences do not show up after dragging any htm file

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P2)

Description

[Patty Mac]

1. Launch Netscape 6.
2. Go to Preferences and select "Themes". It's classic first time
   launch the browser.
3. Make sure anything under preferences can be selectable. 
4. Drag any html file to the browser.
5. Check the preferences again. First need to click the "Appearance" under 
   "Category".   Note that the UI for any item that you select
   from preferences such as, color, fonts, themes, etc..., The contents do not 
   show up.
NOTE: This bug is different from the other bug# 51242
Build: 2000-09-08-04-M18)

Comment 1

[Blake Ross]

*** Bug 51905 has been marked as a duplicate of this bug. ***

Comment 2

[sairuh (rarely reading bugmail)]

not sure if this belongs in preferences or xp toolkit (or, whoever owns this
application of d'n'd). certainly doesn't belong in autofill. :)

Comment 3

[sairuh (rarely reading bugmail)]

oh, wait a sec --is the right panel of the preference just completely blank? i
wonder if this is another symptom of bug 50091?

Comment 4

[John Morrison]

This is only on Windows, and only happens after dragging into mozilla from 
e.g., Nav4.x or a desktop shortcut (not when dragging a URL between mozilla 
browser windows). After that, when you go back into Prefs and change panels,
the entire right hand side panel does not show up. However, a resize of the 
prefs panel will reflow the contents and everything will then show up.
It seems like these are the concrete steps to reproduce bug 50091.

Nom. nsbeta3, as this is not an uncommon scenario during a long session (have 
done a D&D, and want to change a pref). -> pinkerton, to ponder why D&D has 
this side effect.

Comment 5

[John Morrison]

I poked around with this for a while, but didn't discover much more. It is only
after dragging a link (or shortcut) in from another app (or the OS) that this 
starts happening. From the console messages, I can tell that the IFRAME has 
actually loaded (has fired its onload handler). I also found that XUL wizards
are similarily affected (which is not surprising). I checked whether this 
affected HTML IFRAME's in the content windows, but it does not. 

cc: evaughan ... Eric, do you have any idea why the IFRAME in a XUL window would 
not get a reflow (or otherwise prevent the contents from showing?). 

Comment 6

[John Morrison]

cc: evaughan, really, this time.

Comment 7

[Peter Trudelle]

->evaughan. Eric, could you investigate this a bit?

Comment 8

[Eric Vaughan]

Ok I can not reproduce this. If prefs is up its modal. It prevents you from 
dragging onto the browser. So nothing happens. 

Comment 9

[Mike Pinkerton (not reading bugmail)]

i think you misunderstood, eric. if you drag into the browser _then_ open prefs, 
you see the problems. not while prefs is open (obviously).

Comment 10

[John Morrison]

Okay, this is the scenario (abbreviated).
1) start mozilla
2) drag a link from the desktop into the browser content area
3) open the 'Edit->Preferences'
4) switch to another prefs panel

Actual results: the prefs panel is blank

5) resize the prefs dialog window

Actual results: the contents of the iframe are now visible.

Comment 11

[Peter Trudelle]

nsbeta3+, p2, since this looks like memory corruption.

Comment 12

[Eric Vaughan]

The problem is 
nsBaseDragService::StartDragSession is called
BUT
nsBaseDragService::EndDragSession is never called.

So the layout system thinks its still dragging when the new window is opened
which does bad things.

Comment 13

[Eric Vaughan]

Ok I have a fix, All you have to do is make sure you end the session on a 
drop. Please review:

diff -r1.16 nsNativeDragTarget.cpp
307a308,310
>     // tell the drag service that we're done with it
>     mDragService->EndDragSession();
>

Comment 14

[Mike Pinkerton (not reading bugmail)]

the line is right, but i'm not sure about the line # in the diff. I'll apply it, 
and get it landed.

thanks a bunch eric!

Comment 15

[selmer (gone)]

pdt agrees p2.

Comment 16

[Mike Pinkerton (not reading bugmail)]

fixed, thanks again to evaughan.

Comment 17

[sairuh (rarely reading bugmail)]

over to terri to verify (since this is drag'n'drop).

Comment 18

[John Morrison]

Verified fixed win32 2000092908 (was never a mac/linux bug).

(As the fix predates the branch, not marking as different from a trunk
verification).