Xavier Morel
94018575c6
On my system in chrome 92 there are issues of chrome's hitboxes (and rounding) being off leading to tests failures, something which given the adjustment in `triggerMouseEvent` had been an issue in the past. The first test failure was / is in the "correctly display year view" calendar test, where the very first event dialog would fail to open when clicking on the `2016-11-16`. After tracing through fullcalendar, it turned out fullcalendar was told to hit `2016-11-*09*`, suspiciously 7 days before the cell we were looking for in a monthly calendar, hinting to an incorrect vertical offset / hitbox. Fix by offsetting the top coordinate in `triggerMouseEvent`, but rather than just increment by one update the entire thing by trigger the event right in the middle of the element being targeted, that seems more reliable long-term, though it could be slightly confusing for events like mouseenter/mouseover/... The second issue was with a list test, where two cells are supposed to be sized equally. Apparently the offset sizes are supposed to be the rounded version of the actual size (which can be fractional), but dumping the information of `foo` and `text` I'd get real widths (via getBoundingClientRect) of respectively 480.46875 and 480.5, and offsetWidths of 481 and 480 (the smaller of the two in "real size" is rounded higher than the other one). In Python we might use `assertAlmostEqual` for this, but we've apparently not introduced this in JS take the real width and round up by hand, this fixes the issue as both end up at 481. Aside 1: Before finding out the actual root cause I landed in `_onYearDateClick` with missing data in the events so looked at the API to figure what I was looking at, and turns out fullcalendar's event object has documented properties to get the date-converted start and end bounds of the event, so use that directly instead of doing the same thing by hand. Aside 2: The attributes passed to `triggerEvent` in `triggerMouseEvent` are pretty much nonsensical, we're getting the element's location using `getBoundingClientRect` which is based off of the viewport, but setting the keys * `screen(X|Y)`, which should be the location of the hit relative to *the physical screen* * `page(X|Y)`, which should be the location of the hit relative to the page / document (so takes in account the content scrolled off-screen) * `layer(X|Y)`, which is the position of the hit relative to the nearest positioned (non-static) element, falling back to page if there isn't one The one attribute which matches the semantics / reference of `getBoundingClientRect` we didn't even set, instead it would be automatically copied from `pageX`/`pageY` by the events mapping. Fix that by just providing `clientX`/`clientY` and updating the mapping functions to not overwrite it. If the others are needed they should be computed properly based on the document's bounding client rect and scroll information, as well as the window's screenX/screenY (and offsetParent for layerX/layerY though that seems unlikely to be necessary). closes odoo/odoo#75953 X-original-commit: d26a4edffd6bdaed46143a30e99f17eb91f44e7e Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials