search

KawaiiBASIC / classilla

Automatically exported from code.google.com/p/classilla
0 stars 0 forks source link

Fix flyout menus over scrollframes and other challenging widgets #105

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This was a known, complex issue in Mozilla. I'm leery of implementing this
for 9.1 but we do need to implement it. We'll do this in the next layout
update phase. cnet is where I notice it most on the dropdowns overlying ads
but a decent subportion of sites with flyout menus have this problem. It is
limited to overlying widgety things such as scrollframes.

THIS IS WHY ADS ARE BAD

Relevant bugs: M125386 M285000 M297080
https://bugzilla.mozilla.org/show_bug.cgi?id=125386

Original issue reported on code.google.com by classi...@floodgap.com on 12 Feb 2010 at 10:08

GoogleCodeExporter commented 9 years ago 
This is also seen on www.fas.harvard.edu

Original comment by classi...@floodgap.com on 15 Feb 2010 at 9:04

GoogleCodeExporter commented 9 years ago 
Actually, comments 30 and 31 of M125386 should be okay for a first cut.

Original comment by classi...@floodgap.com on 17 Jan 2012 at 9:45

GoogleCodeExporter commented 9 years ago 
We also need M297080 comment 21 (don't use 56), with a GetTopLevelWindow() 
function added to widget/nsWindow.cpp:

8074 nsWindow* nsWindow::GetTopLevelWindow(PRBool aStopOnDialogOrPopup)
8075 {
8076   nsWindow* curWindow = this;
8077 
8078   while (PR_TRUE) {
8079     if (aStopOnDialogOrPopup) {
8080       switch (curWindow->mWindowType) {
8081         case eWindowType_dialog:
8082         case eWindowType_popup:
8083           return curWindow;
8084       }
8085     }
8086 
8087     nsWindow* parentWindow = curWindow->GetParentWindow();
8088 
8089     if (!parentWindow)
8090       return curWindow;
8091 
8092     curWindow = parentWindow;
8093   }
8094 }

We change GetParentWindow() to GetParent(), which we have, and we use 
mWindowPtr instead of gCurrentWindow. There is already code like this in 
nsWindow::DispatchMouseEvent, but it is commented out and appears to be only 
for debugging.

If I ever do a BeOS R5 port, we will also need to solve M422303.

Original comment by classi...@floodgap.com on 17 Jan 2012 at 11:11

GoogleCodeExporter commented 9 years ago 
I think this is solvable without other layout changes, so tentatively scheduled 
for 9.3.1.

Original comment by classi...@floodgap.com on 17 Jan 2012 at 11:12

GoogleCodeExporter commented 9 years ago 
The example from issue 189 exhibits this too.

Original comment by classi...@floodgap.com on 5 Mar 2012 at 12:40

GoogleCodeExporter commented 9 years ago 
Initial work didn't seem to fix issue 189. I'll try it against the test cases 
in the dependent bugs. What issue 189's site might be caused by is 
https://bugzilla.mozilla.org/show_bug.cgi?id=234788 but I haven't found the 
fixing cause.

Original comment by classi...@floodgap.com on 6 Mar 2012 at 4:51

GoogleCodeExporter commented 9 years ago 
We should be able to modify M125386 to cover this case based on 
https://bugzilla.mozilla.org/show_bug.cgi?id=236925

Original comment by classi...@floodgap.com on 6 Mar 2012 at 4:59

GoogleCodeExporter commented 9 years ago 
FIXED!

Original comment by classi...@floodgap.com on 8 Oct 2012 at 11:05

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 19 Oct 2012 at 4:49