Bug 3242 - (int-85612) Page is partially blanked, requiring the user to scroll around to force the page to redraw
(int-85612)
: Page is partially blanked, requiring the user to scroll around to force the p...
Status: RESOLVED FIXED
Product: Browser
MicroB engine
: 4.1 (4.2008.23-14)
: All Maemo
: Low minor (vote)
: 4.1.1
Assigned To: unassigned
: microb-bugs
: http://www.internettablettalk.com/for...
:
:
:
  Show dependency tree
 
Reported: 2008-06-12 10:24 UTC by Ryan Abel
Modified: 2008-08-14 16:27 UTC (History)
5 users (show)

See Also:


Attachments
Mocked-up screenshot showing MicroB page blanking (81.17 KB, image/jpeg)
2008-06-12 10:25 UTC, Ryan Abel
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Ryan Abel (reporter) maemo.org 2008-06-12 10:24:57 UTC
SOFTWARE VERSION:
3.2008.22-8

STEPS TO REPRODUCE THE PROBLEM:

1. Go to a website.
2. Watch the page load, and then part of the page blank as it's rendering.

EXPECTED OUTCOME:
Page renders normally

ACTUAL OUTCOME:
Page does not render normally, and part of the page is blanked, requiring the
user to scroll past the blanking to force the browser to re-render it (much
like you occasionally had to force Windows 98 to re-draw parts of the UI by
dragging windows around).

REPRODUCIBILITY:
Sometimes, maybe about a 3rd of the time. It's usually worse when I try to
scroll the page before it finishes loading.

OTHER COMMENTS:
I'm attaching a mocked up image of what the effect looking like (haven't tried
to get a real screenshot yet, but the effect is the same).

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US)
AppleWebKit/525.18 (KHTML, like Gecko, Safari/525.20) OmniWeb/v622.1.0.101362
Comment 1 Ryan Abel (reporter) maemo.org 2008-06-12 10:25:55 UTC
Created an attachment (id=778) [details]
Mocked-up screenshot showing MicroB page blanking

This is a mock-up showing the page-blanking effect.
Comment 2 timeless 2008-06-12 11:01:03 UTC
if the problem happens for a certain page, please fill in the URL field...
Comment 3 Ryan Abel (reporter) maemo.org 2008-06-12 11:19:52 UTC
(In reply to comment #2)
> if the problem happens for a certain page, please fill in the URL field...
> 

It's not specific to a certain website, has happened all over the place. If you
want a site where it definitely happens, you can always try itT. ;)
Comment 4 Andre Klapper maemo.org 2008-06-16 14:48:31 UTC
I'd really like to have a second person confirming this or a very good testcase
before pushing it into the internal bugtracker.
Comment 5 Faheem Pervez maemo.org 2008-06-16 17:51:47 UTC
I can confirm this bug on a N800 running Diablo 4.2008.23-14. (Microb-engine
1.0.4-60.9)

I shall upload a screenshot when I can reproduce the bug again (soon).
Comment 6 Andre Klapper maemo.org 2008-06-16 18:04:34 UTC
Cool. Now the next item on my wishlist is a reproducible testcase. :-)
Comment 7 John 2008-06-16 18:10:38 UTC
I can also confirm this bug on my N800, Diablo 4.2008.22-8, microb-engine
1.0.4-60.6. I've seen the bug a couple times on google.com. If I remember
correctly, it was after quite a bit of surfing (ie, not the first page I'd
visited), and I may have switched to a different app and then back to the
browser. It seemed to start getting worse after I pulled up the vkb. I had no
more than 2 browser windows open at the time. I will update to the latest
microb-engine release and try and narrow down how to reproduce it.
Comment 8 Eero Tamminen nokia 2008-06-23 16:38:21 UTC
I think this is the issue of Browser UI and engine being in separate
processes in Diablo and the input method not being completely updated
to handle that appropriately (giving WM the HTML engine window ID instead
of the UI window ID for resizing and using the HTML engine window ID for
communicating about the user input).


(In reply to comment #6)
> Cool. Now the next item on my wishlist is a reproducible testcase. :-)

I thought this was already fixed in Diablo so I would be interested about
a test-case also.  I think the test case requires using the input method
and then closing it.
Comment 9 Eero Tamminen nokia 2008-06-24 11:41:02 UTC
(In reply to comment #8)
> I think this is the issue of Browser UI and engine being in separate
> processes in Diablo and the input method not being completely updated
> to handle that appropriately (giving WM the HTML engine window ID instead
> of the UI window ID for resizing and using the HTML engine window ID for
> communicating about the user input).

Checked this with xwininfo, xprop & xev (from x-debug-tools package) and
this doesn't seem to be the case.  Apparently it's related more to XEmbed
and/or the engine expose handling.


> (In reply to comment #6)
> > Cool. Now the next item on my wishlist is a reproducible testcase. :-)
> 
> I thought this was already fixed in Diablo so I would be interested about
> a test-case also.  I think the test case requires using the input method
> and then closing it.

Any comments on this?  Can the bug be triggered without using VKBD
at all in the browser session (just using bookmarks, surfing & panning)?

And if it doesn't require using VKBD, does it require switching between
normal and fullscreen mode (which also causes resize on the browser
engine and UI windows)?
Comment 10 Daniel Martin Yerga 2008-06-27 11:06:10 UTC
It's not necessary to use the virtual keyboard. It happens here without use the
vkb.

It happens in fullscreen mode and in windowed mode. The blank part is repainted
when you go to fullscreen (being in windowed mode) or to normal window (being
in fullscreen mode).

The easier way to reproduce is scrolling the page before it load completely as
pointed out Ryan. But it doesn't happen always.
Comment 11 Andre Klapper maemo.org 2008-06-27 12:02:14 UTC
Bug 3242 looks like another redraw issue, may be related.
Comment 12 Andre Klapper maemo.org 2008-06-27 12:07:32 UTC
According to the internal ticket this problem should be fixed in 
https://garage.maemo.org/svn/browser/mozilla/tags/stable_100608/microb-engine/microb-engine/1.0.4-60.11
, hence closing as FIXED. If anybody can still reproduce this in that revision
(or that release once updates have been made available), please reopen this bug
report.

Thanks!
Comment 13 Andre Klapper maemo.org 2008-06-30 16:44:29 UTC
Setting Target Milestone to "4.1+". This means that the fix will be available
in upgrades for the 4.1 release.
Comment 14 Andre Klapper maemo.org 2008-08-14 16:27:26 UTC
Fix is included in 4.2008.30-2, hence setting Target Milestone correctly to
4.1.1.