509693 - A case of missing "Java frame" on http://www.zonebourse.com/

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.3pre) Gecko/20090810 Shiretoko/3.5.3pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.3pre) Gecko/20090811 SeaMonkey/2.0b2pre] (nightly) (W2Ksp4)

Work fine.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090806 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/5c913c4662d8 + bug 444021 patch
 +http://hg.mozilla.org/comm-central/rev/4344cc9a28a7)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a2pre) Gecko/20090810 Minefield/3.6a2pre] (nightly) (W2Ksp4)

1. Load http://www.zonebourse.com/CAC-40-4941/analyse_technique-plein/

1r. Between the bottom of the chart and the "Graphique statique / Graphique dynamique" links, there is a blank area.
That area should contain a slider and some buttons.

Comment 1

[Serge Gautherie (:sgautherie)]

Regressed between
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090721 Minefield/3.6a1pre] (nightly) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/f2a58ffcd00c)
and
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre] (nightly) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/02f8bf10f441)

Regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2a58ffcd00c&tochange=02f8bf10f441
I would suspect what roc landed...

***

Workaround: Reload (or Back+Forward) fixes it.
(But one has to know there is something missing in the first place :-/)

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The problem here is that ScrollWindowEx with SW_SCROLLCHILDREN seems to not move descendants of child windows that don't intersect the scrolled rectangle, *even if* the immediate child window of the scrolled window *does* intersect the scrolled window. So this applet contains some child windows at the bottom, which are initially out of view. You scroll down, and the applet scrolls into view but its child windows stay where they are relative to the viewport, they effectively move down relative to the applet window (!). It's crazy...

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1: use eWindowType_plugin

For this bug we have to turn off Windows' SW_SCROLLCHILDREN in some cases where windowed plugins use child widgets. I discovered that we were sometimes turning it off because of the FAKESCROLLBAR widget we added to fool the Trackpoint driver. It's definitely unnecessary, and actually wrong, to create the FAKESCROLLBAR for plugin widgets, so let's stop doing that. However to do that we have to know at widget creation time that it's a plugin. eWindowType_plugin exists but hasn't been used. So this patch makes us use it, and changes most places we currently use eWindowType_child to also accept eWindowType_plugin. I'm also removing eWindowType_java because we don't use that (fortunately).

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 2: Make test plugin have a child widget [Checkin: Comment 16]

To write a test for this bug we need the test plugin to have a child widget. We also need to be able to detect if the child widget has moved away from its correct position relative to its parent.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 3: fix

The actual fix. This is rather grotesque but it seems like the best thing to do. I considered dropping all use of SW_SCROLLCHILDREN but it leads to noticeable visual weirdness when we scroll Flash.

The test plugin's child widget is 10x10 positioned at the top-left corner of the plugin. So the test scrolls that child completely out of view, and then tries to scroll it back into view, at which point without the fix the test fails because SW_SCROLLCHILDREN doesn't move the plugin's child widget.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Kyle, just letting you know that in this bug I'm stopping us from creating the Trackpoint fake scrollbar for plugin widgets.

Comment 7

[Jim Mathies [:jimm]]

(In reply to comment #5)
> Created an attachment (id=402556) [details]
> Part 3: fix
> 
> The actual fix. This is rather grotesque but it seems like the best thing to
> do. I considered dropping all use of SW_SCROLLCHILDREN but it leads to
> noticeable visual weirdness when we scroll Flash.
> 
> The test plugin's child widget is 10x10 positioned at the top-left corner of
> the plugin. So the test scrolls that child completely out of view, and then
> tries to scroll it back into view, at which point without the fix the test
> fails because SW_SCROLLCHILDREN doesn't move the plugin's child widget.

With SW_SCROLLCHILDREN removed, what happens with the child window that sits outside the parent? Was SW_SCROLLCHILDREN preventing these windows from being moved and now with it removed, windows handles moving these windows around correctly within the viewport?

Comment 8

[Jim Mathies [:jimm]]

I see so SW_SCROLLCHILDREN acts as a filtering mechanism on all child windows for our scrolling. Seems like the right fix would be to remove SW_SCROLLCHILDREN use completely and then address the flash weirdness. I suppose we need a fix for 1.9.2 that is low risk, so why don't we file a follow up bug to look into removing SW_SCROLLCHILDREN completely for the next release.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

SW_SCROLLCHILDREN selects the subset of *descendant* (not just child) windows that intersect the given rectangle and moves them by the scroll amount. All other descendant windows keep the same absolute position. So a descendant window that doesn't move, but whose parent moves, effectively moves relative to its parent. That's bad, and this patch prevents it.

When SW_SCROLLCHILDREN is not used, ScrollWindowEx does not change the positions of any windows. We have to manually move the windows ourselves. The "weirdness" I referred to is simply the effect you get if you call ScrollWindowEx to blit some area of your window around, and then move the plugin window manually using SetWindowPos or whatever. You see the window contents move and then just slightly later the plugin window moves. The effect is most visible if you drag the scroll thumb around, the plugin just seems to be lagging behind a little. I don't know of any way to prevent that other than to keep using SW_SCROLLCHILDREN when we can.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1 v2

Turns out that nsChildView.mm doesn't set mWindowType from aInitData->mWindowType, so Part 1 broke plugins on Mac. This updated patch makes nsBaseWidget::BaseCreate set mWindowType to aInitData->mWindowType and mBorderStyles to aInitData->mBorderStyles, always, and removes all the other code that various platforms had to initialize those members.

Comment 11

[Josh Aas]

Comment on attachment 402555 [details] [diff] [review]
Part 2: Make test plugin have a child widget
[Checkin: Comment 16]

"Make Windows test plugin iin windowed mode"

misspelled "in"

+static void checkIs(int a, int b, const char* msg, string& error)

Maybe call this "checkEquals" or something that communicates the operation.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1 v2 --- real patch [Checkin: Comment 16]

Sorry, I attached a copy of Part 2 by mistake.

Comment 13

[Jim Mathies [:jimm]]

Comment on attachment 402556 [details] [diff] [review]
Part 3: fix

+		test_plugin_scroll_consistency.html \

Didn't see this test in here anywhere, were you still planning on adding one?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 3 v2 [Checkin: Comment 17]

Sorry Jim, I forgot to hg add the test. Here's a patch which includes the test.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Spot the typo in part 1:

+  if (!mWindowType != eWindowType_plugin) return NS_ERROR_FAILURE;

That caused some nice test failures.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Landed parts 2 and 3:
http://hg.mozilla.org/mozilla-central/rev/f3c07913015f
http://hg.mozilla.org/mozilla-central/rev/bfbd630be11a

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Er, those were parts 1 and 2. Part 3 was
http://hg.mozilla.org/mozilla-central/rev/298772a42ecc

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There were no regressions here. We don't need to hold this for an OS/2 build break fix.

Comment 19

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20091007 Minefield/3.7a1pre] (nightly) (W2Ksp4)

V.Fixed

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/eceb2f7e3145
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1e53cdaa8936
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8f1429f2ff02