registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #19215
[Bug 40320] Re: devhelp starts with an "empty" page area, which is not redrawn
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.
