After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 714065 - White borders appear when message area resized
White borders appear when message area resized
Status: RESOLVED OBSOLETE
Product: geary
Classification: Other
Component: ux
master
Other All
: Low normal
: ---
Assigned To: Geary Maintainers
Geary Maintainers
Depends on: 765516
Blocks:
 
 
Reported: 2013-01-03 01:51 UTC by Eric Gregory
Modified: 2017-12-13 23:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
geary_white_borders.png (171.01 KB, image/png)
2013-01-03 01:51 UTC, Eric Gregory
Details

Description Charles Lindsay 2013-11-21 20:24:38 UTC


---- Reported by eric@yorba.org 2013-01-02 17:51:00 -0800 ----

Original Redmine bug id: 6174
Original URL: http://redmine.yorba.org/issues/6174
Searchable id: yorba-bug-6174
Original author: Eric Gregory
Original description:

While resizing the Geary message area (i.e. dragging the columns) a white
border appears in the message area at the right and bottom.

This is strictly a visual glitch and only occurs while the resize is in
progress. If we can't figure out a way to get the WebKit frame to fill the
entire area, we could probably just get away with painting the container's
background gray.

A screenshot demonstrating the problem is attached.

Related issues:
related to geary - 4804: message area fails to repaint after window
resize (Fixed)



---- Additional Comments From geary-maint@gnome.bugs 2013-04-03 18:22:00 -0700 ----

### History

####

#1

Updated by Jim Nelson 11 months ago

  * **Priority** changed from _Normal_ to _High_
  * **Target version** set to _0.3.0_

Is this a regression of #4804?

####

#2

Updated by Eric Gregory 11 months ago

No, #4804 only applies to after a resize. This is _during_ a resize.

####

#3

Updated by Jim Nelson 9 months ago

  * **Target version** changed from _0.3.0_ to _0.4.0_

####

#4

Updated by Jim Nelson 8 months ago

  * **Target version** changed from _0.4.0_ to _0.5.0_



--- Bug imported by chaz@yorba.org 2013-11-21 20:24 UTC  ---

This bug was previously known as _bug_ 6174 at http://redmine.yorba.org/show_bug.cgi?id=6174
Imported an attachment (id=260849)

Unknown milestone "unknown in product geary. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution 

Comment 1 Jim Nelson 2014-10-09 01:01:55 UTC
I have to wonder if this has something to do with the GtkOverlay we use at the bottom of the conversation viewer to display the hover URL.  For some reason I feel like we hit a similar problem with the composer.
Comment 2 Robert Schroll 2014-10-09 02:03:50 UTC
I see two different, though similar, behaviors.

When expanding the window, I see a thin white border appear on the edge being moved.  I think this is just the region that GTK has alotted but WebKit hasn't had a chance to paint yet.  We may be able to hide this by setting the GTK widget background color to be the same as the HTML background color.

However, when I shrink the window, I see a larger white border on both the bottom and right of the conversation viewer.  These look just the right size for scrollbars to me.  (If I have a vertical scrollbar, I can only get the border at the bottom to appear.)  I suspect that GTK is deciding that the WebView is shrinking below its natural size, so it starts giving it scrollbars.  But then the WebView gets the smaller size and says, "Okay by me," so GTK gets rid of it again.

When we've had trouble with Overlays, it's been synchronizing the HTML painting and the GTK painting.  But we don't worry about that with the URL overlay -- it just covers up whatever's below it.  I don't think it's the culprit.
Comment 3 Jim Nelson 2014-10-09 02:16:41 UTC
That sounds right to me.  Not a big deal, just thought you might have some insight into the problem (which you did).
Comment 4 Michael Gratton 2016-10-07 13:20:33 UTC
We're definitely not getting this any more. I think it's basically been obsoleted by Bug 728002 landing on master, which removed the overlay, but it may need to come back to use an OSD style toaster for link mouseovers. Will keep this open until that gets resolved either way.
Comment 5 Michael Gratton 2017-12-13 23:26:01 UTC
OSD toasters are a while off. Let's not keep bugs open for possible future bugs.