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

Bug #40320 reported by Matthias Klose
30
Affects Status Importance Assigned to Milestone
Gnome DevHelp
Fix Released
Medium
Mozilla Firefox
Fix Released
High
devhelp (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs
firefox (Ubuntu)
Fix Released
Medium
Unassigned
gecko-sharp (Ubuntu)
Fix Released
Medium
Unassigned
gecko-sharp2 (Ubuntu)
Fix Released
Medium
Unassigned
liferea (Ubuntu)
Fix Released
Medium
Unassigned
monodevelop (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

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

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

Created attachment 200071
fix

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

Comment on attachment 200071
fix

This breaks opening of chrome URLs in new windows

Revision history for this message
In , Jf-rameau (jf-rameau) wrote :

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.

Revision history for this message
Matthias Klose (doko) wrote :

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

Revision history for this message
Matthias Klose (doko) wrote : screenshot

screenshot

Revision history for this message
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
Revision history for this message
In , Daniel Holbach (dholbach) wrote :

This breaks devhelp as mentioned over here: https://launchpad.net/distros/ubuntu/+source/devhelp/+bug/40320/

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

Created attachment 219861
updated fix

This fixes the bug and doesn't break chrome.

Revision history for this message
Daniel Holbach (dholbach) wrote :

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

Revision history for this message
sam tygier (samtygier) wrote :

i think this is also effecting liferea

Revision history for this message
Laurent Bigonville (bigon) wrote :

>think this is also effecting liferea

Hep same problem for me in liferea

sam tygier (samtygier)
Changed in liferea:
status: Unconfirmed → Confirmed
Revision history for this message
sam tygier (samtygier) wrote :

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

Revision history for this message
sam tygier (samtygier) wrote :

sorry my bad. i've just seen it.

Revision history for this message
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
Revision history for this message
Sebastian Dröge (slomo) wrote :

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

Revision history for this message
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 :)

Revision history for this message
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)
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
Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

*** Bug 335349 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Blizzard (blizzard) wrote :

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.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

what's his mail ?

Revision history for this message
In , Matthias Clasen (mclasen) wrote :

Robert, can you review this patch ?

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

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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...

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

(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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

Comment on attachment 219861
updated fix

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

Revision history for this message
In , Matthias Clasen (mclasen) wrote :

Created attachment 239384
updated patch

Revision history for this message
In , Caillon (caillon) wrote :

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

Revision history for this message
In , Caillon (caillon) wrote :

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
Revision history for this message
In , Beltzner (beltzner) wrote :

Comment on attachment 219861
updated fix

a=beltzner on behalf of drivers

Revision history for this message
In , Dveditz (dveditz) wrote :

Comment on attachment 219861
updated fix

approved for 1.8.0 branch, a=dveditz for drivers

Revision history for this message
In , Dveditz (dveditz) wrote :

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.

Revision history for this message
In , Anarchy (anarchy) wrote :

(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.

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

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

Changed in devhelp:
status: Confirmed → Fix Released
Revision history for this message
In , Alexander Sack (asac) wrote :

Looks like this has been forgotten on 1.8 branch.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

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

Revision history for this message
In , Alexander Sack (asac) wrote :

Comment on attachment 219861
updated fix

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

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

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.

Revision history for this message
In , Dveditz (dveditz) wrote :

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)?

Revision history for this message
In , Dveditz (dveditz) wrote :

Comment on attachment 219861
updated fix

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

Revision history for this message
In , Dveditz (dveditz) wrote :

Comment on attachment 219861
updated fix

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

Revision history for this message
In , Caillon (caillon) wrote :

Actually, this landed already in this cycle but I forgot to mark the bug.

http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/embedding/browser/gtk/src/EmbedWindow.cpp&rev=MOZILLA_1_8_BRANCH&mark=1.31.12.1

fixed1.8.1.4

Revision history for this message
In , Twalker (twalker) wrote :

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  
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.