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

RESOLVED FIXED in Firefox 27, Firefox OS v1.2

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: smaug, Assigned: smaug)

Tracking

(Blocks: 1 bug)

Trunk
mozilla29
x86_64
Linux
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox27 fixed, firefox28 fixed, firefox29 fixed, firefox-esr24 fixed, b2g-v1.2 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Comment 1

5 years ago
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.
(Assignee)

Comment 2

5 years ago
This sounds very similar to https://bugzilla.mozilla.org/show_bug.cgi?id=522956#c17
(Assignee)

Comment 3

5 years ago
Created attachment 8360767 [details] [diff] [review]
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?
Attachment #8360767 - Flags: review?(roc)
Flags: needinfo?(karlt)
https://hg.mozilla.org/mozilla-central/rev/08422402615a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
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
status-b2g-v1.2: --- → fixed
status-firefox27: --- → fixed
status-firefox28: --- → fixed
status-firefox29: --- → fixed
status-firefox-esr24: --- → unaffected
(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.
Flags: needinfo?(karlt)
You need to log in before you can comment on or make changes to this bug.