Ubuntu

devhelp starts with an "empty" page area, which is not redrawn

Reported by Matthias Klose on 2006-04-20
30
Affects Status Importance Assigned to Milestone
Gnome DevHelp
Fix Released
Medium
Mozilla Firefox
Fix Released
High
devhelp (Ubuntu)
Medium
Ubuntu Desktop Bugs
firefox (Ubuntu)
Medium
Unassigned
gecko-sharp2 (Ubuntu)
Medium
Unassigned
gecko-sharp (Ubuntu)
Medium
Unassigned
liferea (Ubuntu)
Medium
Unassigned
monodevelop (Ubuntu)
Medium
Unassigned

Bug Description

devhelp starts with an "empty" page area, which is not redrawn, see the attached screenshot

Comment on attachment 200071
fix

This breaks opening of chrome URLs in new windows

Other problem with EmbedWindow::GetVisibility.

0) start gtkmozembed with about:blank
1) resize the window

The embed part is borked due to some visibility problem.

2) Click on embed part: the blank page is rightly rendered.

Matthias Klose (doko) wrote :

devhelp starts with an "empty" page area, which is not redrawn, see the attached screenshot

screenshot

Daniel Holbach (dholbach) wrote :

Thanks for the bug report. This bug is known upstream already: http://bugzilla.gnome.org/show_bug.cgi?id=334867 and https://bugzilla.mozilla.org/show_bug.cgi?id=312998

Changed in devhelp:
assignee: nobody → desktop-bugs
status: Unconfirmed → Confirmed

Created attachment 219861
updated fix

This fixes the bug and doesn't break chrome.

Daniel Holbach (dholbach) wrote :

It seems like the patch at https://bugzilla.mozilla.org/attachment.cgi?id=219861&action=view would fix the issue.

sam tygier (samtygier) wrote :

i think this is also effecting liferea

Laurent Bigonville (bigon) wrote :

>think this is also effecting liferea

Hep same problem for me in liferea

sam tygier (samtygier) on 2006-04-26
Changed in liferea:
status: Unconfirmed → Confirmed
sam tygier (samtygier) wrote :

i can't reproduce this in liferea today. i think maybe a gtk update did it.

sam tygier (samtygier) wrote :

sorry my bad. i've just seen it.

Sebastian Dröge (slomo) wrote :

As this is a firefox bug let's set it confirmed there too. I'm currently building a testbuild with that patch and will report back later.

Changed in firefox:
status: Unconfirmed → Confirmed
Changed in gecko-sharp:
status: Unconfirmed → Confirmed
Changed in gecko-sharp2:
status: Unconfirmed → Confirmed
Changed in monodevelop:
status: Unconfirmed → Confirmed
Sebastian Dröge (slomo) wrote :

See bug #5449 for further breakage caused by the same bug.

Sebastian Dröge (slomo) wrote :

I can confirm that this patch fixes it for gecko-sharp*, monodevelop, liferea, devhelp and doesn't break yelp, epiphany, firefox.
Someone with more knowledge about firefox please upload this :)

Ian Jackson (ijackson) wrote :

The fix for this is in 1.5.dfsg+1.5.0.2-0ubuntu2.

Changed in firefox:
status: Confirmed → Fix Released
Sebastian Dröge (slomo) on 2006-05-03
Changed in gecko-sharp:
status: Confirmed → Fix Released
Changed in gecko-sharp2:
status: Confirmed → Fix Released
Changed in liferea:
status: Confirmed → Fix Released
Changed in monodevelop:
status: Confirmed → Fix Released
Changed in devhelp:
status: Confirmed → Fix Released

Comment on attachment 219861
updated fix

I'm not doing reviews for the time being, you're better off asking someone else like roc for a review.

what's his mail ?

Robert, can you review this patch ?

It fixes very visible and embarrassing bugs in gtkembedmoz-using applications.

Comment on attachment 219861
updated fix

I don't understand. && binds tighter than || so when mVisibility is true, this will return true regardless of the mapping state, so I don't know how this fixes the bug. At least parenthesize so it's clear what's going on...

(In reply to comment #10)
> (From update of attachment 219861 [edit])
> I don't understand. && binds tighter than || so when mVisibility is true, this
> will return true regardless of the mapping state, so I don't know how this
> fixes the bug. At least parenthesize so it's clear what's going on...

I know. mVisibility is never set back to PR_FALSE after it's become PR_TRUE once. The problem is just that sometimes the window is already visible even though mVisibility isn't true yet. This patch is just a work-around: it returns true whenever it did previously but fixes the corner-case.
A real fix would investigate why chrome breaks when we just always return the widget's mapped state here.

Comment on attachment 219861
updated fix

OK, please include a comment to that effect, and add the parens. Thanks!

Created attachment 239384
updated patch

cvs commit: Examining .
Checking in EmbedWindow.cpp;
/cvsroot/mozilla/embedding/browser/gtk/src/EmbedWindow.cpp,v <-- EmbedWindow.cpp
new revision: 1.32; previous revision: 1.31
done

Comment on attachment 219861
updated fix

Low risk, embedding only patch that fixes a slew of dependent applications. See e.g. comment 4 and all the things mentioned in that bug report.

Changed in firefox:
status: In Progress → Fix Released

Comment on attachment 219861
updated fix

a=beltzner on behalf of drivers

Comment on attachment 219861
updated fix

approved for 1.8.0 branch, a=dveditz for drivers

fix checked into MOZILLA_1_8_0_BRANCH. Looks like it's not on the 1.8 branch yet but I think that tree is pretty locked down at the moment.

(In reply to comment #18)
> fix checked into MOZILLA_1_8_0_BRANCH. Looks like it's not on the 1.8 branch
> yet but I think that tree is pretty locked down at the moment.
>

When shall we see this on 1.8 branch. It still has not been commited.

That's not how we do business. please visit irc and ask someone to explain it.

Changed in devhelp:
status: Confirmed → Fix Released

Looks like this has been forgotten on 1.8 branch.

You should just ask for approval on the patch, it's unlikely this is going to actually block any 1.8.1.x release.

Comment on attachment 219861
updated fix

Right, but it already has approval for 1.8.1. Re-requesting approval.

Approvals tend to expire once something has missed the release, so re-requesting approval for the next desired milestone is the right thing to do.

Comment on attachment 219861
updated fix

This missed 1.8.1, clearing old approval to avoid confusion.

We had release candidate builds but might have to respin. Could you find someone to land this today or tomorrow (5/5)?

Comment on attachment 219861
updated fix

Unfortunately this request is way too late to squeeze into 1.8.1.4.

Comment on attachment 219861
updated fix

Chris Aillon says he'll land this, approved for 1.8.1.4, a=dveditz for release-drivers

verified with linux 2.0.0.4 rc2

Changed in devhelp:
importance: Unknown → Medium
Changed in firefox:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.