960309 - figure out how to make browser_tabview_bug625269.js pass reliably with Bug 930793 fixed

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=930793#c38

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

So, currently the test passes only because we end up running it fast enough so that
perf mode is still on after page load.
If I force non-perf mode, the test fails occasionally.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

This sounds very similar to https://bugzilla.mozilla.org/show_bug.cgi?id=522956#c17

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: tabview_test_fix.diff

https://tbpl.mozilla.org/?tree=Try&rev=e21fe1ebd028

This seems to help locally, and is based on 
https://bugzilla.mozilla.org/show_bug.cgi?id=522956#c17


(Karl seems to be on vacation)
Karl, do you know if we could somehow get accurate information from gtk, hopefully without doing tons of sync X stuff?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/08422402615a

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/08422402615a

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/cc07e69e7887
https://hg.mozilla.org/releases/mozilla-beta/rev/62074ff7e993
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/fbcfeb33476a

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr24/rev/d90f361f80aa

Comment 8

[Karl Tomlinson (:karlt)]

(In reply to Olli Pettay [:smaug] from comment #3)
> This seems to help locally, and is based on 
> https://bugzilla.mozilla.org/show_bug.cgi?id=522956#c17

> Karl, do you know if we could somehow get accurate information from gtk,
> hopefully without doing tons of sync X stuff?

Bug 522956 comment 17 is about the position, but I guess things were going wrong here because the size dimensions are handled differently from the position.

nsIWidget::GetScreenBounds is returning the size from the most recent resize request or resize (size-allocate) event.  If several resize requests are sent, then several resized events will be received.  The most recently received resized event may not necessarily be the most up to date size, and this would cause problems for resizeBy(), which uses GetScreenBounds.

Perhaps GetScreenBounds() should use gdk_window_get_geometry() for toplevel windows to be consistent with the position info.  Or perhaps OnSizeAllocate could use gdk_window_get_geometry to ensure it doesn't use out-of-date info.

To make things worse, the script can't detect when all the resized events are received because JS resized events are dispatched when a resize request is sent as well as when a native resized event is received.  I don't know why the resized event is generated on request - perhaps that code should be removed.