Closed Bug 434019 Opened 16 years ago Closed 16 years ago

1px borders on flex (month grid)

Categories

(Calendar :: Calendar Frontend, defect)

Mozilla 1.8 Branch
x86
All
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: ovidiu.grigorescu, Unassigned)

References

()

Details

On month/multiweek view, the grid has 1px variation in thickness when resizing window. Meaning that some borders are 1px thinner randomly depending on the resize stop. This I think is related to the box structure and the flex1 elements as I experimented. 

Reproductible: always
App: SB and LT
Ver: SB LT 0.5-0.8 

The comments I'll port from mozilla.dev.apps.calendar where this has been discussed and detailed (see link in ggroups or thread called as this bug)
[Initial comment from me (OP in ng)]

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..
[From ng, from Decathlon]
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 in ng]
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. 
[From ng, from Decathlon]

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 ?
[From ng, from Decathlon]

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:

  <binding id="calendar-month-day-
box">
 
<content>
      <xul:vbox
flex="1">
	<xul:label anonid="day-label" crop="end" class="calendar-month-day-
box-date-label"/>
        <xul:vbox anonid="day-items"/
> >
      </
xul:vbox>
    </
content>


after:

  <binding id="calendar-month-day-
box">
    <content
orient="vertical">
        <xul:label anonid="day-label" crop="end" class="calendar-month-
day-box-date-label"/>
        <xul:vbox anonid="day-items" class="calendar-month-day-box-
items-box" flex="1"/>
    </
content>

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.
[From ng, from Decathlon]

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

before:

<binding id="calendar-month-day-
box">
<content>
<xul:vbox
flex="1">
<xul:label anonid="day-label" crop="end" class="calendar-month-day-box-
date-label"/>
<xul:vbox anonid="day-items"/
> >
</
xul:vbox>
</
content>

after:

<binding id="calendar-month-day-
box">
<content
orient="vertical">
<xul:label anonid="day-label" crop="end" class="calendar-month-day-box-
date-label"/>
<xul:vbox anonid="day-items" class="calendar-month-day-box-items-box"
flex="1"/>
</content>
These are from ng. 

As a result I would list couple of bugs related:

bug 322979 a pach there seams to have changed things a bit (comment 5)
bug 313543 core .. 
bug 218376 core ..


also maybe:
bug 430382 bug 312830 which are rework of views ..

further changes in box structure may bring more (that's why is dep set alike ..)
ovidiu, please stop spamming bugzilla with (mostly) useless reposts from the calendar developer newsgroup!!! 

Everybody here can use Google Groups to take a look at what was said there. So providing a simple URL pointing to the discussion would have been much more constructive.
As already written in the newsgroup long time ago: This issue only affects mozilla1.8 branch builds using the Gecko 1.8 rendering engine. In Trunk builds that use the Gecko 1.9 rendering engine it's already fixed.
Version: unspecified → Mozilla 1.8 Branch
indeed seams so

ps: comment 8, sorry for the spam, that was really stupid. no excuse for such..
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.