1px borders on flex bug ?

ovidiu

unread,

Feb 18, 2008, 8:09:45 AM2/18/08

to

Hello,

This describes what I would call a bug, but need some ideas so to make a
bugzilla entry pertinent or even valid.
This was brought up in a thread started here and moved to support and
called Feature Request: Color Schemes for Calendar Views , also
http://groups.google.com/group/mozilla.support.calendar/browse_frm/thread/3df44965a75773f0/87ae6ecaa5989b07#87ae6ecaa5989b07
I considered a new thread for this, not to disturb the other one.

I tested on win (vista) Thunderbird 2.0.0.9 and Lightning an Sunbird,
but others brought it up an is probably general.

I would describe the bug as this:
*on calendar: grid lines in month/multiweek disappear or thickened by
1px on window resize.

I tried playing with borders, margins, etc on different elements in css
and ended up considering these:
-be it margins or borders or anything, day boxes are sometimes exceeding
their size/place with 1 px resulting in altered representation of
margins, borders or any other element on edges
-it seams to be always the bottom and right sides to behave like this,
with the only exception in having a scrollbar (when many events in a
day) where the lines aside the scroll are shown normally right one and
bottom only under the scroll and the (scroll not being "altered" in
position ? )
-it seams to also affect other Mozilla products, Thunderbird and
Firefox, in terms of displaying the menus or others where a [flex="1"]
appears (meaning that if resizing very slow can actually see elements
"stepping" on certain 1px sometimes)

-well, I can't say that on ff/tb I have "missing" lines, but rather
observe the same "stepping" for one px resulting in a "flickered
motion", but the elements don't actually catch that position where are
not shown. Maybe they somehow avoid that position...

I can assume having a general core issue with rendering such [flex="1"]
elements on resize of window, or rather any element affected/moved by or
within a [flex="1"], but with specific calendar issue, that it actually
allows elements to catch/remain on that misfortuned position/size . I
can also assume that if so, those flex elements are trying to subdivide
the window space and "fail" on certain numbers resulting in a
"compromise" on positioning some elements, or should I say, not being
able to smooth/antialias such stuff.

I have not found relevant bugs on calendar and been indicated about some
on the general products here
Bug 313543 1 px extra border appears and disappears on shrinking window
different amounts -kinda old
Bug 218376 – width of adjacent floats off by 1 px when window resized
-very old
not sure how relevant
I did tested this on TB3.0apre (trunk) and have the same stepping 1px in
separators for example. Dough, like in all the other ff and tb, not
leading to missing lines, but rather just a not so smooth move.

I would ask you
1. If this is a known bug, maybe I just not found
2. If this is a general bug, and again..
3. How should I consider to file it to bugzilla? On calendar, on all
(core), on both, considering something like "daybox blabla" depending on
"the general one.."
4. Nevertheless, is there a workaround for such issue? Not in css I
guess, but I see that TB and FF do not fall into showing stuff on those
ingrate "positions" and ,somehow avoid them..

Thanks for patience on reading such extensive novel ..

Ronald Hermes

unread,

Feb 20, 2008, 1:25:30 PM2/20/08

to

ovidiu schrieb:

Hey Lads,

any news on this topic? Is it a known bug or should it be filed on bugzilla?

Cheers

Decathlon

unread,

Mar 24, 2008, 6:53:13 AM3/24/08

to

Hi.
I've posted a comment on bugzilla about bug 313543
https://bugzilla.mozilla.org/show_bug.cgi?id=313543#c5
that seemed have some relation with this Sunbird/Lightning issue.
As you can read there, bug 313543 isn't present on recent Geko engine
(Firefox 3b4 Gecko/2008030714) but S/L issue is still present even
with the latest nightly build. I tried with TB 2.0.0.14pre (20080321)
and Sunbird 0.8 (Gecko/20080320).

Martijn Wargers, suggested me to file a bug about this issue and make
a minimal testacase (without downloading S/L).
I'm not a developer and I don't know about XUL and CSS but after some
reading I've made a little testcase that reproduces S/L calendar month-
view grid on Firefox window using part of code from files calendar-
month-view.xml and calendar-views.css:
http://lxr.mozilla.org/mozilla/source/calendar/base/content/calendar-month-view.xml
http://lxr.mozilla.org/mozilla/source/calendar/base/themes/winstripe/calendar-views.css
I added a third file (xul) to show and test calendar-view grid
behavior on Firefox resize.

My testcase reproduces the issue on Firefox 2.0.0.12 (Gecko/20080201)
but doesn't with Firefox 3b4 (Gecko/2008030714) the same as bug
313543.
If it can be useful I uploaded these files in zip format here:
http://www.mediafire.com/?dei9ijjynbm

I can't go deeper into the issue and I have no idea how to make a
different testcase that involves latest S/L versions, but I think that
if no bugs have been reported until now, it's time to do it (testcase
or not).
I know it's a minor issue and there are many bigger problems,
specially now that 0.8 is incoming, but S/L calendar view looks more
reliable without this issue and a grid with 1px lines, like every
calendar application (first of all Outlook), can't be implemented if
this issue exists.

Stefan Sitter

unread,

Mar 24, 2008, 7:19:27 AM3/24/08

to

Decathlon schrieb:

> I've posted a comment on bugzilla about bug 313543
> https://bugzilla.mozilla.org/show_bug.cgi?id=313543#c5 that
> seemed have some relation with this Sunbird/Lightning issue. As
> you can read there, bug 313543 isn't present on recent Geko
> engine (Firefox 3b4 Gecko/2008030714) but S/L issue is still
> present even with the latest nightly build. I tried with TB
> 2.0.0.14pre (20080321) and Sunbird 0.8 (Gecko/20080320).

You have tested the wrong builds:
Gecko 1.8: Firefox 2.0.0.*, Thunderbird 2.0.0.*, Sunbird 0.8, ...
Gecko 1.9: Firefox 3.0b4, Thunderbird 3.0a1, Sunbird 0.6a1, ...

To test builds with Gecko 1.9 you need to use a Sunbird, Thunderbird
and Lightning nightly builds from the latest-trunk folders. Check
the user agent for the correct Gecko version (e.g. "rv:1.8..." or
"rv:1.9...") to be sure what you test.

Decathlon

unread,

Mar 25, 2008, 10:09:48 AM3/25/08

to

Stefan Sitter wrote:

> To test builds with Gecko 1.9 you need to use a Sunbird, Thunderbird
> and Lightning nightly builds from the latest-trunk folders. Check
> the user agent for the correct Gecko version (e.g. "rv:1.8..." or
> "rv:1.9...") to be sure what you test.

Thanks for your informations.
I've tried Thunderbird+Lightning and Sunbird versions you posted, both
with Gecko 1.9 (rv:1.9b5pre) and the bug, now I can say that it is
(was) a bug, is vanished.
When will we see S/L versions with Gecko 1.9 ?

Decathlon

unread,

May 14, 2008, 3:43:46 PM5/14/08

to

After bug 312830 has been fixed ( https://bugzilla.mozilla.org/show_bug.cgi?id=322979
), Nightly builds later than build 20080507 have a different day-boxes
structure in calendar-month-view.xml

before:

after:

Now, when you resize Thunderbird's window (or resize left pane or
Today pane, or when select a month with a different number of weeks),
lines between day boxes have a different behavior:
part of the line near the label is always 2pxs thick, part near vbox
becomes occasionally 1px thick like in this image:

http://img375.imageshack.us/my.php?image=monthviewbug1pxawz5.png

The "bug" disappear with the following CSS code in userChrome.css
file:

calendar-month-day-box {
padding-right: 1px !important;
padding-bottom: 1px !important;
}

there's a lot of flickering when you resize from right to left, much
less from left to right, but final view is *always* correct: lines
2pxs thick .

Now it's possible to make a grid in calendar view with lines 1px thick
(that remain always 1px thick when window resizes) by adding to
userChrome.css file a CSS code like this (only essential code):

calendar-month-day-box {
padding-right: 1px !important;
padding-bottom: 1px !important;
border: none !important;
border-left: 1px solid #3F7D91 !important;
border-bottom: 1px solid #3F7D91 !important;
}
.calendar-month-view-grid-row{
border-right: 1px solid #3F7D91 !important;
}
calendar-month-view-column-header {
border-bottom: 1px solid #3F7D91 !important;
}

Obviously without padding the problem persist: lines are 1px thick but
disappear, now only part of them, when window resizes or calendar view
has a different number of day-boxes.

I'm not into XUL and I'm not able to understand why this workaround
works after bug 312830 has been fixed and didn't work before (although
I would like to understand it).

If someone could verify this, and check if it's possible to use it to
change calendar view in permanent way, it'll be great because Lg\Sb
interfaces would be more attractive.

Thanks for your attention.

Decathlon

unread,

May 14, 2008, 3:54:43 PM5/14/08

to

Sorry for the caos (hope this will be better):

before:

after:

<xul:vbox anonid="day-items" class="calendar-month-day-box-items-box"
flex="1"/>
</content>

ovidiu

unread,

May 16, 2008, 5:04:40 AM5/16/08

to

I just created
https://bugzilla.mozilla.org/show_bug.cgi?id=434019

we should keep further track of this there .