40901 - While mozilla is frozen, dropdowns are "always on top"

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Jesse Ruderman]

If mozilla freezes while a dropdown is dropped down, the dropped-down part 
stays on top of other (non-mozilla) windows.  I think this happens with crashes 
as well.

Steps to reproduce:
1. Load testcase
2. Pull dropdown down and wait for a second
3. Switch to another application and try to cover the dropdown

The testcase exploits bug 13350 (mozilla is unresponsive while running JS).

Comment 1

[John Morrison]

Hmm, well no testcase here, but a bit of js like:

function loopForever() {
  window.status = "looping now";
  while(true) {
  };
}
setTimeout("loopForever();", 10000);

would exploit bug #bug 13350. However, I'm not sure that this bug isn't just
equal to bug #13350 -- there is no callback from js, which starves the
UI, which means that the popups never get a message to tear themselves down.

Are there other ways that mozilla can get into this state, and are any of them
not equivalent to a complete lockup? In other words, when the callback is 
implemented, this shouldn't be a problem anymore, no?

(BTW, this applies to both HTML Form Controls and to XPToolkit Widgets).

Comment 2

[Jesse Ruderman]

Attachment: test case

Comment 3

[Jesse Ruderman]

Oh yeah, actually attaching the testcase would have been a good idea :)

This bug wasn't meant to depend on bug 13350 -- it was meant to demonstrate 
another bug that happens during a freeze, using 13350 for the freeze.  Sorry 
for the confusion.

Comment 4

[John Morrison]

Yes, but I'd argue that the solution to this problem is equal to the solution
to bug 13350 -- implement a callback into the DOM so that UI events don't get
completely hosed when JS runs wild. [That is, unless there is some other way
to get into this state that doesn't involve looping in JS (either directly or
indirectly].

Comment 5

[Jesse Ruderman]

There are zillions of ways to crash or freeze mozilla...

Comment 6

[rods (gone)]

*** This bug has been marked as a duplicate of 13350 ***

Comment 7

[Jesse Ruderman]

This is not a dup of bug 13350.  This bug is something that happens during 
freezes.  Bug 13350 is one my many exploitable bugs that freezes mozilla.

Comment 8

[rods (gone)]

It's a duplicate because the UI thread is starved for events so the combobox 
never gets the event that tells it roll up the drop down. There is nothing I can 
do it fix this bug. Once 13350 is fixed this bug will be fixed too, so it is a 
duplicate. Please mark it as one. thanks

Comment 9

[Jesse Ruderman]

This bug won't go away when bug 13350 is fixed!  It happens whenever a 
crash/freeze is triggered while a dropdown is dropped down.

This bug could be marked as depending on bug 25472 (don't crash) and bug 30942 
(don't freeze), or it could be marked as WONTFIX.  Blaming a specific crasher 
for the problem isn't the right thing to do.

(What is it about native widgets that allows other windows programs to not have 
this bug?)

Comment 10

[rods (gone)]

ok, well it isn't a bug that will get looked at until afer FCS.

Comment 11

[Jesse Ruderman]

Fair enough.

Comment 12

[Peter Trudelle]

Hyatt sez this sounds like view manager, but it is no longer a component.  Who
should get this, or should it be resolved as wontfix?

Comment 13

[rods (gone)]

I think this is a won't fix. Mozilla really shouldn't be "freezing"

Comment 14

[Peter Trudelle]

making it so