[Blama]

Hi Isomorphic,

testing with the dragGhostCustomization sample (SNAPSHOT_v15.0d_2026-03-18) I can see that all the issues above are fixed!

I found other issues, though.

1. If you make the Sub-day event in the sample an All-day event in the GUI and click OK and then edit it again and remove the "All-day", the time portion is as before, so it must somehow still be part of the event data. Is this a bug?
2. #1 here makes me wonder again how events are persisted. See also #31.1. Could you switch the sample to use a DataSource (clientOnly or persisted)? Then one could also easily see what is expected w.r.t. to default DB column names.
3. In month view, when the Calendar is displaying a previous or a next month, like April 2026 in the sample with no further changes, a click on the cell area of Mon 2026-03-30, Tue 2026-03-30 or Fri 2026-05-01 switches the display to the respective month (expected). This is not true for a click in the Ghost Space, which creates an All-Day event (unexpected).
4. As above, a click on Sun 2026-03-29 or Sat 2026-05-02 does not do this. This is because of disableWeekends: true, but IMHO the month switching should still happen.

I also have general disableWeekends feedback/questions, which I will post below.

Best regards
Blama

[Isomorphic]

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+.

[Isomorphic]

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.

[Blama]

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:


#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

[Isomorphic]

hi Blama,

We've made a bunch of fixes and improvements - here's how they relate to your reports:

- 24.0 - we've updated the sample to include 4 events: sub-day, all-day, multi-day and all-day + multi-day.
    Also made value-changes in the formItems redraw the Calendar right away

- 25.2 - we don't see this effect by setting minimumDayHeight: 400, in 13.1 or 15.0, or in Chrome/Firefox. The
  header remains at 30px (in Spacious), and the body gets the rest of the height. However:
  - we'd be interested to know your OS/Browser setup if you still see this issue in the Showcase
      - 13.1 vs 15.0 - the latter uses an optimized grid-rendering mode by default (LG.divGrid/centralStyling)
  - we've shored up this logic and made some changes anyway
      - Calendar.monthDayHeaderHeight (20px) and monthDayBodyHeight (null) now let you control the sizes
        separately, if you wish
      - fixes to tricky space-sharing logic now mean that you'll rarely see rows resize as you drag/drop events
        into them, as you noted earlier in the thread
      - cell-content will now shrink when the longEventsLayout increases in height, with a min of one
        link-height for existing link-events (or "More...")

- 25.3 - this is fixed

- 26.1 - we're also not seeing this in 13.1 or 15.0, Chrome/FF - the ghost is always well-placed and properly
  sized, and the popup always shows the right range - but note that there have been almost daily recent changes
  in this code, and lots of new autotests now exercise it - so perhaps just retest this one and let us know

- 27.1 and .2 - these are fixed

- 28.1 and .3 - these are fixed
- 28.2 and .4 - we're not going to make any changes for these cosmetic issues for the moment - if we do, it'll
  likely be in 15.0 only

Most of these fixes are already in today's 15.0, and they'll all be in 13.1+ in tomorrow's builds, dated March 9 and later.

[Isomorphic]

Thanks Blama - we'll take a look at these various issues and update here when we've fixed them.

[Blama]

Hi Isomorphic,

also some minor feedback on the "New Event"-Detail window:

1) Different to the Mini-"New Event" window, this one does not close on "Esc"-key. From testing it, it would be better if both closed on "Esc"-key.

2) The height setting for the components can probably be optimized. If you have a very high calendar (for many events in month view), the layout for this one is not nice, too much space between To/From and OK/Cancel buttons. Please test with height: 1000 for the VLayout of this sample.
Probably the Window should not use 100% of the Calendar size.

3) Please enable "Multi day" and then toggle "All day" a few times. You will see that the name of the start field jumps between "Date" and "From", while the "End" name stays constant. I think it should always be "From" for "Multi Day"-Events.

4) There might be an Alinment issue with validation error for All-Day-Multi-Day events. Not sure this is expected or an issue:



That's it for now. It's really cool to see this coming along, as it is looking great and will be a fabulous addition!

Best regards
Blama

[Blama]

Hi Isomorphic,

continuing and probably related to your #23.6:

In Month-View All-Day-events created in the Cell section eventually are 12:00-13:00 only.

In this video it is happening immediately after Sample start, Switch to Month View, but sometimes it takes a few event creation attempts to trigger.


Also, events normal events created in the Month View Cell area show an end time of 23:59 for a split second (visible in the video). This is unexpected.


Best regards
Blama

[Blama]

Hi Isomorphic,

continuing the previous post, this is what I mean:


Steps to reproduce:

• Start sample
• Clear existing events
• Drag create events like in the video

Issues:

• 1st event: Thu-Fri is fine
• 2nd event is Fri only, should also be Thu-Fri
• 3rd event is Thu-Fri (OK), but the Ghost Canvas shows Thu-Sat.

Best regards
Blama

[Blama]

Hi Isomorphic,

I retested here with SNAPSHOT_v15.0d_2026-03-05.

1) I can see that the [All day] naming works now

2) I can see that Calendar.minimumDayHeight works, but not as expected, it also affects the row with the day-numbers (in the sample height: 1000 for the Layout and minimumDayHeight: 400 for the Calendar).


3) I can see the click is now cancelled as expected, but saw this behaviour somewhere else as well today, but could not reproduce yet.
Also, drag-create of multi day events over existing events does not work, only in the ghost area or "at the other side" of the existing event. See when exactly the Ghost Canvas size changes in the video. I assume this is related, and the over is cancelled while on over existing events.


4) I can see revalidation happens.

5) Thanks, the sample is great.

6) I might have found a similar issue in week view. Will post in a new comment here, if not related.


Best regards
Blama

[Blama]

Hi Isomorphic,

thanks, I will retest with a new build. Regarding the new sample: That's great, makes testing easier.

One thing I noticed is that the events-end is 00:00, while I'd expect 23:59. The way it is right now, the two events seem to be 3 or 4 days long, but don't show up in the last day in Day-view. I assume this is just a sample setup error.

Perhaps you can add All-Day, Multi-Day and All-Day-Multi-Day events by default, so that it's easier to test.

Best regards
Blama

[Isomorphic]

hi Blama,

We've just committed a bunch of fixes and enhancements that'll hit tomorrow's builds.

On the things you mentioned:

1. the All Day="canvas in a recordComponent " rule now works, with the addition that any drag-created multi-day event (in the layout or the cell) is now also defaulted to All Day - and the popup dialog shows [All Day] in the title, as appropriate

2. you can set calendar.minimumDayHeight to get fixed (min) height rows - make that 200 and you'll get more room

3. drag-moving a multi-day event in the WeekView, so that its start-date is still within the original range of the event (eg, drag a two-day event 1-day to the right) no longer shows the eventEditor on drop

4. validation in the eventEditor is now comprehensive, and re-validation happens when values change and when the allDay or multiDay checkboxes are toggled

5. the docs - the attribute-names changed again, for those that had only been around for a day or so - the old mechanism of showing a full-height longEvent during drag was considered a bug (couldn't see it if there were real events present), and has been removed altogether. The new feature is controlled by:

- longEventLayoutSpace: the (existing) drag-area height
- dragGhostSpaceVAlign: drag-area placement, top/bottom, above/below real events - default top
- dragGhostHeight: the height of the actual ghost canvas, default 4px
- dragGhostVAlign: the alignment of the ghost-canvas in the drag-area space, default center

There's a 15.0 sample you can play with, here.

6. also fixed a tricky MonthView bug where drag-creating a multi-day event by starting the drag in the cell body, rather than the longEventsLayout, would show the ghost in the correct cell initially but wouldn't expand if dragged into the cell immediately to its right - any other cell worked fine - similar issue to #3

[Blama]

Hi Isomorphic,

I retested with SNAPSHOT_v15.0d_2026-03-03.
Thanks for the explanation of All-Day(=recordComponent) and Normal(=Cell content) events. That then makes sense.
Would it be possible to have fixed week heights in Month-View, even if this is wasting screen real estate? This still might make sense if the Calendar is tall enough. This content moving seems disturbing to the eye and somehow wrong.

The new ghost Canvas are really nice.

Other than that, I found an issue with month switching and All-day event placing in month view:


Here in week and month view "clicks" for Drag-And-Drop are not cancelled, if you move the start date to a day where the event was already happening.
Create an event 24th/25th. Moving it to 25th/26th shows the event detail box (unexpected), because the click is not cancelled. If you move it back and then move it to 26th/27th, the event detail box is not shown (expected):



Also, there are no validation errors for start > end when you click "Save event" (unexpected). It does work in Non-All-Day mode, where you can see the time portion.



The docs don't seem to have longEventCompactDrag (mentioned in the other thread) and longEventDragVAlign (mentioned in #21).

Best regards
Blama

[Isomorphic]

hi Blama,

All the changes made to 15.0 to date are now available in today's builds of 13.1+, along with various other fixes applied over the last few days.

For your reference, long-events are displayed in a recordComponent that sits above cells - in the MonthView, regular events are displayed as links in the cell-content, below the recordComponent, so they can't, right now, be mixed with longEvents and aligned in the way you showed, with a long-event next to a regular event.

However, we do still have some other tweaks to make here.

Note that for resizing due to the ghost-canvas being displayed in a layout, we've made two enhancements here, which will be in tomorrow's builds.

1. in the case of the existing mode, where a full-height longEvent ghost is shown, the default height of longEventLayouts now matches longEventHeight, so rows will no longer resize during drag-create unless they are already full of regular events. However, this mode has an issue, in that you can't see the ghost-canvas particularly well, because it renders on top of any existing events.

2. a new mode, the default, shows the ghost-event in the 10px area that is always present in longEventsLayouts - the canvas is rendered at 10px (or whatever longEventLayoutSpace is set to) and does not show text - but it is guaranteed to always be visible, whether there are existing events in the layout or not. By default, this space is visible below existing events in each layout, and you can change it to appear above them via longEventDragVAlign.

[Blama]

Hi Isomorphic,

thanks, I'll wait for a new build and retest.
To clarify, with 1) (new events after the 1st are always All-day) I meant in the Month-view. The logic of where the click is decides the type works as you say in Day and Week-view. In Week-view even for multi day events.

And also for 3) dynamic height of the longEventsLayouts I was taking about the Month-view (like in the video in #18). The current size increase in Day- and Week-View makes sense to me and also looks good.
If you also were taking about Month-View: Is there a difference between Normal and All-Day events in the Week-view, apart from the design? I don't think there needs to be w.r.t. to placing. Here in google calendar the normal and All-day events are being treated equally and placed next to each other.



Best regards
Blama