Open
Bug 72046
Opened 24 years ago
Updated 2 years ago
on resize block contents should not be reflown unless block width/height changes.
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
REOPENED
People
(Reporter: alexeyc2003, Unassigned)
Details
(Keywords: perf, testcase)
Attachments
(1 file)
647 bytes,
text/html
|
Details |
OS: Win2K
Build: 2001031320
I believe an unnecesary reflow is performed inside block-elements when on
container resize block dimensions do not change.
I think it would be better visually and performancewise if the whole block just
been shifted, without reflow performed inside of it, unless block dimensions change.
When you slowly resize the following attachment, you'll notice that table
contents appear all wobbly and shift themselves around inside the table box.
Caption text, table cells, cell text - everything bounces back and forth when it
really shouldn't.
I believe on BIG and complex tables a lot of performance speed up could be
achieved if blocks were reflowed only when they change dimensions.
I'm not familiar with the Mozilla code itself, and don't know, if this can be done.
Also a concern comes to mind about HTML entities with absolute positions which
can be contained inside such blocks and how they should be handled.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
With provided testcase, the smaller you resize the window, the more evident the
wobbling inside elements is. This also affects UI elements in Mozilla. For
example when you horisontally size down the window, images inside browser
toolbar buttons start to bounce around in Classic theme. I also seen this effect
when resizing columns in Mail thread pane, and a few other places. Their
contents was bouncing around, even though nor their size nor their position was
changed.
I'm still seeing this on Win2K Build 2001042504.
Changing component from HTMLElement to Layout because I think reflow stuff might
belong there.
CCing David Hyatt, so he has a look at this.
Component: HTML Element → Layout
Comment 3•23 years ago
|
||
settign status to NEW. Adding qawanted keyword.
HTML Element component is deprecated, and should be removed from Bugzilla.
Clayton is not the correct owner for these. Reassigning to layout.
Assignee: clayton → karnaze
QA Contact: bsharma → petersen
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 6•21 years ago
|
||
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: petersen → ian
Target Milestone: Future → ---
Comment 7•20 years ago
|
||
> I think it would be better visually and performancewise if the whole block just
> been shifted, without reflow performed inside of it, unless block dimensions
> change.
Not good enough when, say, floats are involved...
Comment 8•16 years ago
|
||
Pretty sure this is a fixed as it will get at this point.
Reporter | ||
Comment 9•16 years ago
|
||
I tried the testcase again.
The contents of table elements looks pretty solid during resize.
However the contents of DIV elements is still bouncing around during resize (Gecko/2008092417 Firefox/3.0.3).
Comment 10•16 years ago
|
||
Just stepping through this in a debugger, the reflow of the fixed-width div is a no-op on trunk, since its one inline line is not dirty.
I strongly suspect that any bouncing you see is due to the rounding happening when fractional-pixel margins are blitted to an integer-pixel screen, not due to us reflowing the fixed-width block...
Updated•15 years ago
|
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
Comment 11•11 years ago
|
||
Windows 2000 support has been dropped a while ago. Please only reopen this bug if you can reproduce it on Windows XP or older with current Firefox builds.
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Comment 12•11 years ago
|
||
Ioana, there appears to be nothing win2k-specific about this bug. Please don't resolve bugs as wontfix based on their (bogus, automatically set by Bugzilla) OS field without actually trying to reproduce them.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 13•11 years ago
|
||
Windows 2000 is specified clearly in comment 0 and there are no other OSs mentioned in this bug.
As said before, in my experience with Win2k bugs, most of them didn't reproduce on Win XP or 7. What OS do you think would be suitable to try and reproduce such bugs on?
Comment 14•11 years ago
|
||
For this bug, any OS: it's describing what sounds like a cross-platform problem if it exists at all.
Comment 15•11 years ago
|
||
WFM on: Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0
I'n not seeing any bouncing for table elements, nor the div.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Reporter | ||
Comment 16•11 years ago
|
||
Tried this on Linux:
Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0
The behaviour seems to be reversed to Comment 9:
* Centered text, table caption and fixed width DIV are all solid during resize.
* Text inside table cells is bouncing around though.
REOPENING
Boris, would you be able to run the same debug check on table cells as the one you run on DIV in comment 10?
Status: RESOLVED → REOPENED
OS: Windows 2000 → All
Resolution: WORKSFORME → ---
Comment 17•11 years ago
|
||
Yes, but possibly not till after I get back week after next.
Flags: needinfo?(bzbarsky)
Comment 18•11 years ago
|
||
nsTableCellFrame::Reflow is not hit in this testcase when I resize the window.
But nsTableRowFrame::Reflow is.
Flags: needinfo?(bzbarsky)
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•