526768 - Tracker bug for 1.9.2 bustage on 11/05 nightly build

Status: RESOLVED DUPLICATE of bug 527615

(Core :: Widget: Gtk, defect)

Description

[Aakash Desai [:aakashd]]

Apparently, whatever broke trunk:

- shows up in maximized mode
- very crashy

...now landed on 1.9.2 builds last night. This might require re-opening a bug that's already in our database, but let's use this to track our sleuthing.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Last good build:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mobile-1.9.2/1257395051

 First bad build:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mobile-1.9.2/1257404988

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Last good changeset:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ef2339f4305a

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

After bisecting the changesets, it looks like I found the regression in this one:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/13433c466f46

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

I backed out the bad changeset

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

verified with 20091106 1.9.2 nightly build on n810

Comment 6

[Karl Tomlinson (:karlt)]

Reopening because this hasn't been fixed.

Version -> Trunk
because bug 509278 comment 56 says this is still a problem on m-c.

(In reply to comment #0)
> - very crashy

Can someone get a crash stack for me, please?

Comment 7

[Karl Tomlinson (:karlt)]

Bug 509278 comment 54 says:
This patch seens to have affect Fennec in at leaset two ways:
1. The application no longer starts in fullscreen, even though the front-end
code thinks it is fullscreen
2. Scrolling/Panning creates lots of visual tearing

See bug 526768

Comment 8

[Karl Tomlinson (:karlt)]

I built mobile-browser befb5bade9e2 against m-c fbf102197d2c on desktop x86_64 Linux, then compared with the change in bug 526768 reverted.

(In reply to comment #7)
> 1. The application no longer starts in fullscreen, even though the front-end
> code thinks it is fullscreen

Even without the change the application doesn't start in fullscreen.
Does the application provide a way to switch to fullscreen?
(I didn't observe any effect with F11.)

I used the window manager to switch to fullscreen and back and didn't notice any difference in the appearance of the application (even without the fix for bug 526768).  How can I tell whether the front-end code thinks it is fullscreen?

> 2. Scrolling/Panning creates lots of visual tearing

I saw similar tearing of vertical lines when scrolling horizontally with and without the fix for bug 526768.  This is expected unless there is a mechanism for syncing painting with the monitor.  Is there such a mechanism?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> (In reply to comment #7)
> > 1. The application no longer starts in fullscreen, even though the front-end
> > code thinks it is fullscreen
> 
> Even without the change the application doesn't start in fullscreen.

You need an n810/n900 to test this (we don't startup fullscreen on the desktop). You can probably test on the desktop by modifying http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.xul#59 to always take the sizemode="fullscreen" path.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #8)
> I built mobile-browser befb5bade9e2 against m-c fbf102197d2c on desktop x86_64
> Linux, then compared with the change in bug 526768 reverted.

Unfortunately, I did not see any problems with a desktop build. Only on the N900/N810.

> > 2. Scrolling/Panning creates lots of visual tearing
> 
> I saw similar tearing of vertical lines when scrolling horizontally with and
> without the fix for bug 526768.  This is expected unless there is a mechanism
> for syncing painting with the monitor.  Is there such a mechanism?

I saw tearing while scrolling vertically. The tearing did not exist with the patch backed out

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to comment #10)
> I saw tearing while scrolling vertically. The tearing did not exist with the
> patch backed out

Was this in the content, or the side bars, or both?

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #11)
> (In reply to comment #10)
> > I saw tearing while scrolling vertically. The tearing did not exist with the
> > patch backed out
> 
> Was this in the content, or the side bars, or both?

Both. The entire window was tearing as I scrolled

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

Examples of tearing while scrolling:
http://people.mozilla.com/~mfinkle/fennec/screenshots/fennec-n900-tearing-bug-01.png
http://people.mozilla.com/~mfinkle/fennec/screenshots/fennec-n900-tearing-bug-02.png

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

Karl asked me to make some small changes, compile and test on N900 to see if anything made a difference.

1: http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.cpp#2066
change to: if (!mGdkWindow)

2: http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.cpp#968
comment out the early return

#1 had no affect.
#2 allowed Fennec to open in fullscreen and I was unable to get any tearing while scrolling.

Comment 15

[Karl Tomlinson (:karlt)]

Thanks very much, Mark and Gavin, for your help with this.

I'll tentatively mark this as a dupe of bug 527615.

Reopen with stacks or steps to reproduce if the crashes are still happening.