page hight calculation must be done for every page
Bug #885727 reported by
Ferdinand
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Odoo Web (MOVED TO GITHUB) |
Confirmed
|
Wishlist
|
OpenERP R&D Web Team | ||
Bug Description
Example
webkit header/footers
the vertical size seems to be taken from the first notebook page although the 3 other pages have text widgets which would need to use the available window hight
Revision history for this message
| Ferdinand (office-chricar) wrote | #1 |
| Changed in openerp-web: | |
| assignee: | nobody → OpenERP R&D Web Team (openerp-dev-web) |
| importance: | Undecided → Low |
| status: | New → Confirmed |
Revision history for this message
| Xavier (Open ERP) (xmo-deactivatedaccount) wrote | #2 |
| Changed in openerp-web: | |
| importance: | Low → Wishlist |
Revision history for this message
| Xavier (Open ERP) (xmo-deactivatedaccount) wrote | #3 |
Revision history for this message
| Xavier (Open ERP) (xmo-deactivatedaccount) wrote | #4 |
To post a comment you must log in.
> the vertical size seems to be taken from the first notebook page
There is no vertical size calculation at all. The footer is "stuck" to the bottom of the viewport (unless the content pushes it further down). The vertical height of tabs in a notebook are fully independent from one another and depend only on the height of their content.
> although the 3 other pages have text widgets which would need to use the available window height
I can see where you're coming from, but I'm moving this to wishlist: it would be nice, it's not necessary, and it would require significant work to get it right as vertical layouting (instead of just letting elements stack on top of one another) is very tricky, work which is currently needed to fix stuff that's not actually working.
* We can't just naively set all parents to have a height of 100%, as that's going to expand the first tab as well and it's going to "punch through" the footer (see screenshots 1 and 2)
* The size limitation does not come from just the tab content, most of the parents are not explicitly sized so some sort of automatic computation is going to be broken… pretty much always, it's never going to work right. It *might* be possible to make every textarea size itself to display all of its content (although this is not a feature supported in HTML itself) it's not going to be simple either, and it's definitely going to create problems in other views
* Setting a bigger default height (currently 6 rows) for text fields (HTML textareas) is going to affect all textareas, it's certainly possible to increase that size a bit but not to take the whole screen or it's going to break pretty much every view using textareas on top of something else.
* The last possibility would be to add an option to explicitly specify the height of text fields in the view, that could certainly work (for low enough values of work) but would not exactly be sexy.