maemo.org Bugzilla – Bug 3242
Page is partially blanked, requiring the user to scroll around to force the page to redraw
Last modified: 2008-08-14 16:27:26 UTC
You need to
before you can comment on or make changes to this bug.
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.
Page renders normally
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).
Sometimes, maybe about a 3rd of the time. It's usually worse when I try to
scroll the page before it finishes loading.
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/v618.104.22.168362
Created an attachment (id=778) [details]
Mocked-up screenshot showing MicroB page blanking
This is a mock-up showing the page-blanking effect.
if the problem happens for a certain page, please fill in the URL field...
(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. ;)
I'd really like to have a second person confirming this or a very good testcase
before pushing it into the internal bugtracker.
I can confirm this bug on a N800 running Diablo 4.2008.23-14. (Microb-engine
I shall upload a screenshot when I can reproduce the bug again (soon).
Cool. Now the next item on my wishlist is a reproducible testcase. :-)
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.
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.
(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)?
It's not necessary to use the virtual keyboard. It happens here without use the
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.
Bug 3242 looks like another redraw issue, may be related.
According to the internal ticket this problem should be fixed in
, 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
Setting Target Milestone to "4.1+". This means that the fix will be available
in upgrades for the 4.1 release.
Fix is included in 4.2008.30-2, hence setting Target Milestone correctly to