- Before this commit
Keyboard navigation in dropdowns lead to a traceback
- Explanation
The traceback happens in the bootstrap library.
When upgrading to bootstrap v5.1.3 (see c48f57e), a fix done in the
previous bootstrap version was lost (see 78f85f2).
This previous fix also added a test but it was not enough to
detect the issue when the bootstrap lib was upgraded.
- After this commit
This commit reintroduce the same previous fix and adapts the test,
hoping it would be enough for future changes to not break further
the expected behavior.
closesodoo/odoo#108080
X-original-commit: daca8fe4e3da4a5ad5fabf3730496a3919af8abc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Some modules used Bootstrap minified bundle but this was replaced
in [1] to avoid using of minified files.
We now want to have the same way to import bootstrap by using non-minified
individually compiled Bootstrap files (bootstrap/js/dist/).
Note that in 'hw_drivers', the js and css part was imported at the
same time but the javascript seems never used...
REF:
[1] https://github.com/odoo/odoo/pull/95450
Part-of: odoo/odoo#95628
* = base,http_routing,hw_drivers
- Update Bootstrap from 4.3.1 to 5.1.3
- Update PopperJS to version 2 for Bootstrap 5 (JS part)
Some code was for PopperJS V1, but it's not compatible anymore.
- Remove some BS5 classes utilities backport
- Fix path for BS5
Task ID: 2766483
Part-of: odoo/odoo#95450
ENCOUNTERED ISSUE:
Unable to close a dropdown with ESC when the focus has been given
to a select element inside the dropdown.
TO REPRODUCE:
i.e. in the searchpanel, go to "FilterMenu > Add Custom Filter" and
open the field select element.
Press ESC once: the field select element closes just fine.
Press ESC a 2nd time: we expect the dropdown to close but nothing occur.
REASON EXPLANATION:
Since 84715436d our Dropdown component uses the 'dropdown-menu'
bootstrap class.
But under some conditions bootstrap stops the keydown events propagation
when the event.target matches the query selector '.dropdown-menu'.
IMPLEMENTED FIX:
This commit refines this selector directly inside the bootstrap library.
This is admittedly a bad practice but:
- this modification is trivial and sensible
- the modified selector is only used locally
in the bootstrap's 'dropdown.js' file
- the added test should prevent the lost of
this customization in the future
task-2764821
Part-of: odoo/odoo#84969
See https://blog.getbootstrap.com/2019/02/11/bootstrap-4-3-0/
and https://blog.getbootstrap.com/2019/02/13/bootstrap-4-3-1-and-3-4-1/
Again, some fixes were added in this version and not in a 4.2.x version
so there is no clean way to backport them in 12.0 / saas-12.2.
If needed, the file bootstrap_review.scss is there for that.
Among the new features, two notable ones:
- The '.modal-dialog-scrollable' class which does what odoo already
implemented for all its modals. So we could remove our custom code in
a next update.
- Responsive font sizes ! Plan was to develop something similar for the
website, so this comes at the right time. The behavior is opt-in, we
will enable it in a next update.
Part of https://github.com/odoo/odoo/pull/31401
task-1944790
We're not shipping the sourcemap files, and while the assets minifier
strips out the mappings they're getting hit in debug=assets which is
bot useless and problematic when running odoo-bin without a proxy for
static folders: if sourcemaps are enabled (which is apparently the
default in all browsers if devtools are opened at this point) the
browser tries to fetch the sourcemap, which does through the
SharedDataMiddleware which doesn't find them and passes the query on
to the regular Application which goes through the entire dispatch &
NotFound process.
If website is installed, that process ends up rendering website.404,
which can be pretty costly until everything is properly cached:
# initial request
"GET /web/static/lib/bootstrap/js/index.js.map HTTP/1.1" 404 - 319 0.198 0.954
# a few requests later
"GET /web/static/lib/bootstrap/js/index.js.map HTTP/1.1" 404 - 27 0.022 0.060
And the way sourcemaps are fetched (might be headers, might be the
stampede as browsers will try to fetch a dozen sourcemaps as fast as
possible) seems to make this problem much, much worse: instead of 300+
the requests take 800+ queries each, multiple seconds, and requests
get worse as time goes on (didn't investigate the exact reason for
that) *and* they apparently don't ever get cached (at least they don't
after half a dozen reloads of the client).
Before this commit the bootstrap version we used was inconsistent.
Indeed, the javascript files were the 3.3.4 ones and the less files
were the 3.3.5 ones. This was due to a failed merged resolution in 9.0.
This should however not cause any issue as the difference between
3.3.x versions are very minor.
Basically, this commit is more of a fix than an improvement and may
even be backported if we find reasons to do so. This commit is mainly
made to prepare the transition to version 4.0.0, which requires to
switch our LESS files to SCSS first (and it will be easier to go by
bootstrap 3.3.7 with SCSS files first).
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
Bruno Boi