Launchpad has imported 30 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=312998.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2005-10-19T12:25:04+00:00 chpe wrote: gtkmozembed's EmbedWindow::GetVisibility function doesn't work right: when the internal state is 'visible' but the widget is not mapped (for example because it's in a GtkNotebook and not the current tab), it still returns true. That means that the focus checking code incorrectly allows setting the focus to a textarea widget in this tab, messing up the focus in the active tab. Steps to reproduce: 0) Start Epiphany 1) Load http://www.gnome.org/~chpe/testcases/test-othertab.html in tab 0 2) Load http://www.gnome.org/~chpe/testcases/test-textarea.html in tab 1 3) Move mouse over the textarea in tab 1 4) Switch back to tab 0 5) Try to type something in the textarea or input field Result: The background tab continously makes the foreground tab lose input focus. The fix is simple: check if the widget is mapped! + *aVisibility = mVisibility && + mOwner->mOwningWidget && + GTK_WIDGET_MAPPED(mOwner->mOwningWidget); I didn't know whether ::GetVisibility might be called after the widget is destroyed, so I added the mOwner->mOwningWidget safetty check. This is the same thing for gtkmozembed as bug 306245 was for camino. This patch does NOT make my patch from bug 303730 obsolete, since there can be more than one mapped gtkmozembed in the toplevel window (e.g. the main tab, and the sidebar embed). Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/0 ------------------------------------------------------------------------ On 2005-10-19T12:25:37+00:00 chpe wrote: Created attachment 200071 fix Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/1 ------------------------------------------------------------------------ On 2005-11-16T21:38:57+00:00 chpe wrote: Comment on attachment 200071 fix This breaks opening of chrome URLs in new windows Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/2 ------------------------------------------------------------------------ On 2005-11-16T21:44:31+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/3 ------------------------------------------------------------------------ On 2006-04-20T14:59:10+00:00 Daniel Holbach wrote: This breaks devhelp as mentioned over here: https://launchpad.net/distros/ubuntu/+source/devhelp/+bug/40320/ Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/7 ------------------------------------------------------------------------ On 2006-04-26T11:07:09+00:00 chpe wrote: Created attachment 219861 updated fix This fixes the bug and doesn't break chrome. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/8 ------------------------------------------------------------------------ On 2006-05-11T10:34:58+00:00 chpe wrote: *** Bug 335349 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/18 ------------------------------------------------------------------------ On 2006-08-28T19:19:25+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/19 ------------------------------------------------------------------------ On 2006-08-28T19:34:30+00:00 Mh+mozilla wrote: what's his mail ? Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/20 ------------------------------------------------------------------------ On 2006-09-15T19:55:40+00:00 Matthias Clasen wrote: Robert, can you review this patch ? It fixes very visible and embarrassing bugs in gtkembedmoz-using applications. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/21 ------------------------------------------------------------------------ On 2006-09-18T22:59:02+00:00 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... Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/22 ------------------------------------------------------------------------ On 2006-09-18T23:19:12+00:00 chpe 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/23 ------------------------------------------------------------------------ On 2006-09-19T02:18:11+00:00 Roc-ocallahan wrote: Comment on attachment 219861 updated fix OK, please include a comment to that effect, and add the parens. Thanks! Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/24 ------------------------------------------------------------------------ On 2006-09-20T18:36:45+00:00 Matthias Clasen wrote: Created attachment 239384 updated patch Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/25 ------------------------------------------------------------------------ On 2006-09-27T00:46:06+00:00 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 Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/26 ------------------------------------------------------------------------ On 2006-09-27T00:50:08+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/27 ------------------------------------------------------------------------ On 2006-09-27T17:36:16+00:00 Beltzner wrote: Comment on attachment 219861 updated fix a=beltzner on behalf of drivers Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/28 ------------------------------------------------------------------------ On 2006-09-29T18:44:53+00:00 Dveditz wrote: Comment on attachment 219861 updated fix approved for 1.8.0 branch, a=dveditz for drivers Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/29 ------------------------------------------------------------------------ On 2006-10-06T20:27:27+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/30 ------------------------------------------------------------------------ On 2007-01-03T04:41:55+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/31 ------------------------------------------------------------------------ On 2007-01-03T15:49:47+00:00 Timeless-bemail wrote: That's not how we do business. please visit irc and ask someone to explain it. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/32 ------------------------------------------------------------------------ On 2007-05-02T23:59:28+00:00 Alexander Sack wrote: Looks like this has been forgotten on 1.8 branch. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/33 ------------------------------------------------------------------------ On 2007-05-03T00:29:32+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/34 ------------------------------------------------------------------------ On 2007-05-03T09:35:44+00:00 Alexander Sack wrote: Comment on attachment 219861 updated fix Right, but it already has approval for 1.8.1. Re-requesting approval. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/35 ------------------------------------------------------------------------ On 2007-05-03T15:14:23+00:00 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. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/36 ------------------------------------------------------------------------ On 2007-05-05T02:55:02+00:00 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)? Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/37 ------------------------------------------------------------------------ On 2007-05-07T17:25:02+00:00 Dveditz wrote: Comment on attachment 219861 updated fix Unfortunately this request is way too late to squeeze into 1.8.1.4. Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/38 ------------------------------------------------------------------------ On 2007-05-07T17:29:16+00:00 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 Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/39 ------------------------------------------------------------------------ On 2007-05-07T17:43:09+00:00 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 Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/40 ------------------------------------------------------------------------ On 2007-05-15T18:13:21+00:00 Twalker wrote: verified with linux 2.0.0.4 rc2 Reply at: https://bugs.launchpad.net/devhelp/+bug/40320/comments/41 ** Changed in: firefox Importance: Unknown => High -- devhelp starts with an "empty" page area, which is not redrawn https://bugs.launchpad.net/bugs/40320 You received this bug notification because you are a member of Registry Administrators, which is the registrant for Gnome DevHelp. _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : [email protected] Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
