Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    #31
    Hi Isomorphic,

    thanks. The new sample will make testing easier. Testing here again (SNAPSHOT_v15.0d_2026-03-12). Could you also add it to 13.1p? Already the point two below here would profit from it.

    #24.0:
    I noticed this difference with "All-day" vs "All-day Multi-day. The former event still has a time portion in the sample code. Is this on purpose? As this sample is without a DataSource one can't see what is gonna be persisted. But either you will need an "isAllDay"-column in the DB, or you need a convention 0:00-23:59 means "all day".

    #25.2:
    I do not notice it in 15.0d or 13.1p in Chromium 146. I also don't notice it in Firefox 148 in v13.1p_2026-03-12. It only happens with Firefox in 15.0d. There the day-number-row is way too high and in total the height of day-number-row and event-content-row is less than in the three other tested scenarios. (tested with Calendar: minimumDayHeight: 700 and VLayout: height: 1000)

    #25.3:
    I can see this is fixed

    #26.1:
    This is still happening and I think I found the reason:
    1st, remove all long events.
    Then if you start dragging and stay inside the Ghost Canvas (on the 2nd day), everything is fine. But if you move out of the Ghost Canvas into the narrow area around it (still inside longEventLayoutSpace), this happens. Strangely setting a higher longEventLayoutSpace doesn't make it easier to trigger, so just use the sample as-is. I can reproduce almost every time, as it is fiddly with the mouse. Just play around with it for a bit.
    Also the Ghost Canvas showing one event more to the right can be reproduced this way.

    #27.1:
    Still happening for me:
    Click image for larger version

Name:	New Event wrong.png
Views:	15
Size:	54.8 KB
ID:	277288

    #27.2:
    Still happening for me.

    #28.1 + #28.3:
    I can see these are fixed.

    #28.2 + #28.4:
    OK, just wanted to point that out.



    Best regards
    Blama

    Comment


      #32
      hi Blama, thanks for the feedback.

      From a quick test of 25.2, we can indeed see the issue of over-tall day-header rows in the MonthView in Firefox, in 15.0 only. From that, we assume we'll see the others too, with sufficient testing in 15.0 Firefox. As we noted - ListGrid's have a new default rendering mode in 15.0, which is optimized for smaller HTML and flex-based layout, and the HTML/CSS for this mode differ a bit in Firefox, by necessity.

      We'll make sure all of these issues are addressed in Chrome and Firefox - in the meantime, if you wanted to know whether what you're reporting is specific to that new rendering mode in 15.0, you can switch it off with calendar.useDivGridMode: false (it's undocumented, but it sets two documented properties on the views, LG.divGrid: false and LG.centralStyling: false).

      That will switch to the legacy TABLE mode and behavior should then match 13.1. In the case of #25.2, you'll see the headers appear at the right height if you do this.

      We'll update here when things hit the builds.
      Last edited by Isomorphic; 13 Mar 2026, 08:34.

      Comment


        #33
        hi Blama,

        Some of the reports you listed are in pretty tricky code, where requirements for a bunch separate features interact during mouse events and so on - but they should all be fixed in today's builds of 15.0, which you can try out just now if you like - and we've added rafts of regression autotests to prevent re-emergence.

        All the changes, including the new Showcase sample, should also be in 14.1 today, although some may have missed the build cutoff - either way, everything is now checked into 13.1+, so everything will be in tomorrow's builds of 13.1+.



        Comment

        Working...
        X