[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, 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.

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

[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,

1. No, that's not a bug. An allDay event is just a regular event (including times) with its allDay flag set, and the default length of a new event (they were always sub-day until recently) has always been an hour from 12 noon to 1pm.
2. See the docs for Calendar.allDayField - we could add a databound example as well, there shouldn't be any difference (and autotests exercise both modes)
3. we'll take a look at this shortly
4. and this one

[Blama]

Hi Isomorphic,

more issues in Mouse interaction:

1. Sometimes you can click-create All-Day events on Sundays in Month View (unexpected). Does not always work, so must be area related or minimal Drag-And-Drop? FF 148 and Edge 146, v13.1p_2026-03-13 and SNAPSHOT_v15.0d_2026-03-18. In Edge 146 more it seems.
   
2. Sometimes you can click-create All-Day events on Sundays in Month View by clicking the All-Day event area at the top of Sunday (unexpected). This only works for one event and seems to happen more in the lower area of the Ghost Space.
   

Best regards
Blama

[Blama]

Hi Isomorphic,

regarding #35.1/2:
What I meant is not that the time is 12 noon to 1pm, which I would expect. It is 1:00 till 2:59, like in the sample code. So setting the All-Day flag does not seem to null out the time portion. IMHO this should happen after a click on OK. Otherwise it will be confusing in persisted data.

Because of this I think a sample with persisted data would be good. Perhaps even with a Validator in the DataSource definition to see the effect of validation errors.

Best regards
Blama

[Isomorphic]

hi Blama,

We'll take a look at the reports in post #36.

No, setting the allDay flag does not null out the time-portion (we assume you mean set it to 12-noon, so it's a logical-date) - if allDay is set, it doesn't matter what the time-portion is, it's ignored, but leaving it there means that if you uncheck the All Day checkbox, you have sensible time values in the editors. This seems like good behavior - if you tick the All Day box, the times disappear, if you untick it again, the times are still there. We understand that you're saying a successful Save should clear the time-portions, but since we'd have to set the times to *something*, they can't be null, it seems sensible to keep the times that were already there.

But we're happy to reconsider if you have specific thoughts.

We'll add a DS-backed sample anyway.

[Blama]

Hi Isomorphic,

I understand the behaviour in the editor and agree this is the best thing to do.
For the "Save event" click and an All-Day event I'd try to persist the time portion as follows:
Start: 00:00:00 (or whatever you have to do because of the timezone)
End: 23:59:59 (or whatever you have to do because of the timezone)

But I agree this isn't easy in general, also for All-Day events. I'd assume the second portion should always be 00 for start and 59 for end. This way the data is more easy to use in other systems.

More general:
I assume you will always want to use DataSourceField.fieldType datetime objects and columns, even for All-Day events? Or are just date fields also OK for all-day events? Would mean more columns in the Database I assume. I can see how this is not easy :)

Best regards
Blama

[Isomorphic]

hi Blama,

You are a very determined developer, sir - watching the videos of you trying to hit these issues with repeated clicks is mesmerizing! :)

We've made some changes:

#34.3/4 are fixed

# 36.1/2 are fixed

On post #39 - we haven't made any changes here just yet. The problem with making events span from midnight to 23:59 is that they'll fill the entire calendar in vertical views. They won't be considered all-day events (in terms of them being displayed as horizontal long-events), even if they span 00:00 to 23:59. The current behavior of retaining the existing start/end times seems better - if you click to create a sub-day event, it'll have time noon-1pm, check the All Day checkbox and save, then you click the event to re-open it, un-check the All Day checkbox and save, it'll have the times it was created with. If you change the times to 00:00 and 23:59, those times will be retained in the same way. On the question about dates vs datetimes - we'll have to have a bit of a look and get back to you on that.

We haven't added a new databound sample just yet, but one should be added in time for tomorrow's builds - probably more than one, actually.