Closed Bug 45562 Opened 24 years ago Closed 24 years ago

[MARGIN-C]Text input shifts down after two character entered

Categories

(Core :: Layout: Form Controls, defect, P2)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: make, Assigned: rbs)

References

Details

(4 keywords, Whiteboard: [nsbeta3-] relnote-devel [fix in hand])

Attachments

(6 files)

testcase
1.17 KB, text/html
Details
testcase showing similar problem
269 bytes, text/html
Details
very simple testcase
81 bytes, text/html
Details
Listing of nsBlockFrame::Reflow() to illustrate the problem
6.36 KB, text/plain
Details
possible patch (obtained with 'cvs diff -u25' !)
5.64 KB, text/plain
Details
Proposed patch
3.92 KB, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (WinNT; U) BuildID: 2000071420 An edit control (input[type=text]) with an negative bottom margin is initially drawn with a bottom margin of 0px. After entering at least two characters, the style property suddenly gets applied and causes a reflow. The effect may be reversed if all entered characters are deleted. Reproducible: Always Steps to Reproduce: 1. Load the attached testcase 2. Enter two characters in the edit control 3. Select and delete them. Actual Results: See description. Expected Results: The negative bottom margin should be applied initially. Entering characters should never cause a reflow or height changes of the edit control.
Keywords: css2, testcase
Attached file testcase —
This is probably something with the margin collapsing code, although I'm not sure. There are some weird things going on that I want to fix sometime... It might be checking for empty lines without checking for a height on inline-block-ish things, or something like that. Any other ideas as to what could be doing this?
Keywords: css2 → css1
Summary: Negative bottom margin on edit control applied only if at least two characters entered → [MARGIN-C]Negative bottom margin on edit control applied only if at least two characters entered
It appears that the GfxText is passing back all the right values out of Reflow (or maybe I should say that the Boxframe is passing back the right values), so this is looking like a table bug.
Assignee: rods → karnaze
Roger, could this have something to do with baseline-alignment propogation? See the second example - the word "Summary:" to the left of the input shifts around as if the baseline were moving.
When I use <tr valign="top|baseline"> in your attachment, I don't see the flickering (my build has the diffs in bug 10207 to enable valign="baseline"). When I use <tr valign="middle|bottom">, I see the flickering when the second character is entered, and when the input filed is cleared (either manually or with a reset button). Putting a border on the table gives a visual clue to the effect that the height of the cell/row is not changing. So it isn't a weird mutation of bug 39885. Puzzling... But I am seeing a lot messages like these: nsLineLayout: nsGfxControlFrame2@00B247F0 didn't set max-element-size! nsLineLayout: nsGfxControlFrame2@00B247F0 didn't set max-element-size! nsLineLayout: nsGfxControlFrame2@00B247F0 didn't set max-element-size! nsLineLayout: nsGfxControlFrame2@00B247F0 didn't set max-element-size! nsLineLayout: nsGfxControlFrame2@00B247F0 didn't set max-element-size! nsLineLayout: nsGfxControlFrame2@00B247F0 didn't set max-element-size! ... Re-assigning back to rods because the GfxText is forgetting to do something that can lead to troubles in the table land. Fixing this will help to see what comes next.
Assignee: karnaze → rods
Sounds like that's where the problem comes from. Indeed, when I wrap the <td> in <td><div>...</div></td>, all goes well (because <div> is taking care of fixing up the missing max-element size).
Triaging Rods bug list. Setting Milestone to M22
Status: NEW → ASSIGNED
Target Milestone: --- → M22
Marking nsbeta3- This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Keywords: relnote
Whiteboard: [nsbeta3-]
Target Milestone: M22 → Future
Clearing milestone target to trigger re-evaluation of this bug. The whole issues that may be surrounding the bug need not be fixed, but the max-element size needs to be set. Indeed, the GfxText is doing a bad thing by not setting the max-element size. I remember to have seen other bugzilla bugs where this breach of the reflow protocol can lead to all sorts of undue ramifications like multiple layout and multiple paints. Also, setting the max-element-size should be fairly easy to do for the GfxText given that there are not floating elements to worry about. In this context of the GfxText, the max-element size should simply be set to the desired size that is presently being returned by its reflow method.
Target Milestone: Future → ---
mjudge: See rbs's comments above about potential reflow performance problems. Clearing the nsbeta3- and nominating for nsbeta3.
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Rod: Are there serious reflow implications if we do not fix this bug for nsbeta3? Are we setting max-element size for the GfxTextControlFrame?
Whiteboard: [NEEDINFO]
There may be side-effects but what exactly could happen is unclear. c.f. also bug 6517.
*** Bug 47807 has been marked as a duplicate of this bug. ***
Attached file very simple testcase —
This is either a block layout issue or a block layout issue in conjunction with tables. I have verified that the GfxText is always passing back the same sizes (including maxelementsize) so it has to be a block issue. IMPORTANT: If the GfxText and the radio are on the same line in the html file the problem does NOT occur, but when you put them on separate lines the problem shows up. Which makes it very weird because the "\n" in between the input elements shouldn't make a difference. But it does. When dumpping the frames the "\n" creates a text frame that is 4 pixels wide and 19 pixels high. If I keep them on the same line and put in a 4px span, or nbsp it works. But if I keep them on the same line and put just a space in between them this DOES cause the problem. Summary: Placing a return immediately after the GfxText with the radio on the next line fails or leaving them on the same line with any number of spaces in between them fails.
Assignee: rods → attinasi
Status: ASSIGNED → NEW
Bogus "didn't set max-element size", "\n" is interfering, lot of weirdness here Cc:ing waterson
*** Bug 41959 has been marked as a duplicate of this bug. ***
Note that bug 41959 has been marked a dup of this bug, and it has a good set of testcases showing how whitespace is affecting &nbsp; in blocks (background colors on tables and collapsing of DIVs). This looks like a very serious regression, probably to line layout but I am not sure. Waterson, can you check it out in your copious spare time?
Status: NEW → ASSIGNED
I will look into this immediately...
Assignee: attinasi → waterson
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Priority: P3 → P2
I'm not seeing this problem now. Because of the comments about the whitespace in the markup I am thinking that this may have been yet another nsTextTransformer problem?
marc, I'm still seeing the problem in the 2nd and 3rd test cases (typing more than one character causes text field to be repositioned). Do you have mods in your tree that I don't?
Nope - I *am* seeing the problem in the second and third tesctase. (...must have been those 5 margaritas I had for lunch...)
Whiteboard: [NEEDINFO] → [nsbeta3-]
Target Milestone: --- → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
The testcase with a css specified margin works fine. The other two test cases do not specify a margin with CSS or HTML, so this isn't really a standards compliance issue per se... Updating Summary.
Summary: [MARGIN-C]Negative bottom margin on edit control applied only if at least two characters entered → [MARGIN-C]Text input shifts down after two character entered
See also bug 61195, which seems to be linux-only.
*** Bug 64519 has been marked as a duplicate of this bug. ***
*** Bug 64519 has been marked as a duplicate of this bug. ***
Bug 64519, which is a duplicate of this, was apparent on all platforms and all os's. Changing "Platform" and "OS" to reflect that fact.
OS: Windows NT → All
Hardware: PC → All
The problem is due to something weird in the code. Here is the trace of what is happening for the second test case which has 2 cells in a table-row. The trace shows that the block code is reporting a changing desired size (compare the line marked with '>> BAD >>' against the lines marked with '>> OK >>'). This later causes the table-row and the table to be shorter. 1) Dump when the page is loaded ------------------------------- TO::Rfl en 00CF02A8 rea=0 av=(14370,UC) comp=(0,0) count=702 T::Rfl en 00CF02FC rea=0 av=(14370,UC) comp=(UC,UC) count=703 TRG::Rfl 00CF0364 rea=0 av=(UC,UC) comp=(UC,UC) count=704 TR::Rfl en 00CF03A8 rea=0 av=(UC,UC) comp=(UC,UC) count=705 TC::Rfl 00CF03F8 rea=0 av=(UC,UC) comp=(UC,UC) count=706 Area::Rfl en 00CF0458 rea=0 av=(UC,UC) comp=(UC,UC) count=707 Area::Rfl ex 00CF0458 des=(900,285) maxElem=(900,285) TC::Rfl ex 00CF03F8 des=(930,315) maxElem=(930,315) TC::Rfl 00CF0508 rea=0 av=(UC,UC) comp=(UC,UC) count=708 Area::Rfl en 00CF0568 rea=0 av=(UC,UC) comp=(UC,UC) count=709 **************GfxText::Rfl en 00CF05F0 rea=0 av=(UC,UC) comp=(UC,UC) **************GfxText::Rfl ex 00CF05F0 des=(3735,360) maxElem=(3735,360) >> OK >> Area::Rfl ex 00CF0568 des=(5925,420) maxElem=(3735,360) TC::Rfl ex 00CF0508 des=(5955,450) maxElem=(3765,390) TR::Rfl ex 00CF03A8 des=(7005,450) maxElem=(4695,390) TRG::Rfl ex 00CF0364 des=(UC,480) maxElem=(4695,390) TRG::Rfl 00CF0364 rea=2 av=(6975,UC) comp=(6975,UC) count=710 TR::Rfl en 00CF03A8 rea=2 av=(6975,UC) comp=(6975,UC) count=711 TC::Rfl 00CF03F8 rea=2 av=(930,UC) comp=(900,UC) count=712 Area::Rfl en 00CF0458 rea=2 av=(900,UC) comp=(900,UC) count=713 Area::Rfl ex 00CF0458 des=(900,285) TC::Rfl ex 00CF03F8 des=(930,315) TC::Rfl 00CF0508 rea=2 av=(5955,UC) comp=(5925,UC) count=714 Area::Rfl en 00CF0568 rea=2 av=(5925,UC) comp=(5925,UC) count=715 >> OK >> Area::Rfl ex 00CF0568 des=(5925,420) TC::Rfl ex 00CF0508 des=(5955,450) TR::Rfl ex 00CF03A8 des=(6945,450) TRG::Rfl ex 00CF0364 des=(6975,450) T::Rfl ex 00CF02FC des=(6975,510) TO::Rfl ex 00CF02A8 des=(6975,510) 2) Dump when the first character is typed in -------------------------------------------- TO::Rfl en 00CF02A8 rea=1 av=(14370,UC) comp=(0,0) count=716 T::Rfl en 00CF02FC rea=1 av=(14370,UC) comp=(UC,UC) count=717 TRG::Rfl 00CF0364 rea=1 av=(6975,UC) comp=(6975,UC) count=718 TR::Rfl en 00CF03A8 rea=1 av=(6975,UC) comp=(6975,UC) count=719 TC::Rfl 00CF0508 rea=1 av=(5955,UC) comp=(5925,UC) count=720 Area::Rfl en 00CF0568 rea=1 av=(5925,UC) comp=(5925,UC) count=721 **************GfxText::Rfl en 00CF05F0 rea=2 av=(UC,UC) comp=(UC,UC) **************GfxText::Rfl ex 00CF05F0 des=(3735,360) maxElem=(3735,360) **************GfxText::Rfl en 00CF05F0 rea=2 av=(5925,UC) comp=(UC,UC) **************GfxText::Rfl ex 00CF05F0 des=(3735,360) >> OK >> Area::Rfl ex 00CF0568 des=(5925,420) maxElem=(3735,360)max=5925 TC::Rfl ex 00CF0508 des=(5955,450) maxElem=(3765,390)max=5955 TR::Rfl ex 00CF03A8 des=(6975,450) max=0 TRG::Rfl ex 00CF0364 des=(6975,450) max=0 T::Rfl ex 00CF02FC des=(6975,510) max=6975 TO::Rfl ex 00CF02A8 des=(6975,510) 3) Dump when the second character is typed in --------------------------------------------- TO::Rfl en 00CF02A8 rea=1 av=(14370,UC) comp=(0,0) count=722 T::Rfl en 00CF02FC rea=1 av=(14370,UC) comp=(UC,UC) count=723 TRG::Rfl 00CF0364 rea=1 av=(6975,UC) comp=(6975,UC) count=724 TR::Rfl en 00CF03A8 rea=1 av=(6975,UC) comp=(6975,UC) count=725 TC::Rfl 00CF0508 rea=1 av=(5955,UC) comp=(5925,UC) count=726 Area::Rfl en 00CF0568 rea=1 av=(5925,UC) comp=(5925,UC) count=727 **************GfxText::Rfl en 00CF05F0 rea=1 av=(UC,UC) comp=(UC,UC) **************GfxText::Rfl ex 00CF05F0 des=(3735,360) maxElem=(3735,360) **************GfxText::Rfl en 00CF05F0 rea=2 av=(5925,UC) comp=(UC,UC) **************GfxText::Rfl ex 00CF05F0 des=(3735,360) >> BAD >> Area::Rfl ex 00CF0568 des=(5925,360) maxElem=(3735,360)max=5925 TC::Rfl ex 00CF0508 des=(5955,390) maxElem=(3765,390)max=5955 TR::Rfl ex 00CF03A8 des=(6975,390) max=0 TRG::Rfl ex 00CF0364 des=(6975,390) max=0 T::Rfl ex 00CF02FC des=(6975,450) max=6975 TO::Rfl ex 00CF02A8 des=(6975,450)
This is a tough one! After further digging, it appears that the difference when entering the two incremental reflows of the block (the good reflow and the bad reflow) is in the target frames [aReflowState.reflowCommand->GetTarget(target)]. When the first character is typed in, the target is the *same* at the 'secret' inner block child that is used to format the table-cell content (i.e., the frame Area@00CF0568 in the dump above). Hence, the code-sections wrapped in tests like 'if (this == target)' are executed by nsBlockFrame. When the second character is typed in, the target frame for this new incremental reflow is *not the same* as the inner block frame anymore (but this new target remains the same for the following characters). The tests 'if (this == target)' are now false and so a different code path is executed by nsBlockFrame, leading to a different height of the block at the end. And that's why there is this mysterious flickering between the first character and the second character. It is not clear if characters following the first character are treated differently by Ender (for example, if they are treated as insertions, or something like that, which have some different effect in the content model and the way the ContentChanged cascade is propagated)...
*** Bug 46844 has been marked as a duplicate of this bug. ***
About the patch: the final size of the block is computed by the function ComputeFinalSize(). This function is called only twice in nsBlockFrame::Relow(), and indeed no where else. On one code path, some adjustments can still be made to the metrics even after the call to ComputeFinalSize(). On the other code path, these adjustments are not present. The patch replicates the adjustements. If this is indeed the proper thing to do, then a cleaner fix is to simply add those adjustments once for all in the ComputeFinalSize() function itself. The patch also fixes the other (duplicate) shifting bugs that I could across.
Errata: one my flag for activation/desactivation was left in... + if (0 && NS_BLOCK_WRAP_SIZE & mState) { should be: + if (NS_BLOCK_WRAP_SIZE & mState) {
What do you layout folks think of this? Also, the analysis calls into question why the max-element-size is not adjusted as well. Aren't there any side-effects in this respect? [Some earlier typos: s/I could across/I could come across/; s/one my/one of my/]
Bug 65435 might be a dup.
Yep, it is a dup and the patch fixes it too.
*** Bug 65435 has been marked as a duplicate of this bug. ***
What frames involved here have their NS_BLOCK_WRAP_SIZE state bit set? It seems strange that any of them should...
The block_wrap_size bit appears to be set on the inner block frame. Here is another run which indicates whether the bit is set or not. [bwz=0]TO::Rfl en 00D43470 rea=1 av=(8940,UC) [bwz=0]T::Rfl en 00D434C4 rea=1 av=(8940,UC) [bwz=0]TRG::Rfl 00D4352C rea=1 av=(6975,UC [bwz=0]TR::Rfl en 00D43570 rea=1 av=(697 [bwz=0]TC::Rfl 00D436D0 rea=1 av=(5955 [bwz=1]Area::Rfl en 00D43730 rea=1 a [bwz=0]**************GfxText::Rfl en 00D4377C re [bwz=0]**************GfxText::Rfl ex 00D4377C de [bwz=0]**************GfxText::Rfl en 00D4377C re [bwz=0]**************GfxText::Rfl ex 00D4377C de [bwz=1]Area::Rfl ex 00D43730 des=(59 [bwz=0]TC::Rfl ex 00D436D0 des=(5955,4 [bwz=0]TR::Rfl ex 00D43570 des=(6975,450 [bwz=0]TRG::Rfl ex 00D4352C des=(6975,450) [bwz=0]T::Rfl ex 00D434C4 des=(6975,510) max [bwz=0]TO::Rfl ex 00D43470 des=(6975,510)
*** Bug 65620 has been marked as a duplicate of this bug. ***
Nominating for nsbeta1: several dups, makes the browser look unstable, and there's a patch :) Also adding top100 keyword from dup bug 64519.
Keywords: nsbeta1, top100
Attached file Proposed patch —
Taking and seeking r/sr to check-in. In the patch I have: (1) moved the ajustements into the single location of the ComputeFinalSize() function itself, (2) kept the max-element-size in sync.
Assignee: waterson → rbs
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.8
+ aMetrics.maxElementSize->height = aMetrics.height; ... + aMetrics.maxElementSize->height = aMetrics.height; Inadvertant redundance. I removed the first in my tree.
I'll be out of town Monday and Tuesday. So... marc or karnaze: please review waterson: please sr rbs: a slightly more detailed description of what you did and why you did it would be a big help to these guys. Thanks.
OK, here is snapshot of what I could understand from this bug. It is a block bug exposed by Ender/GfxText, and it is having cascading effects in tables, making the bug hard to track and giving the impression that it is an incremental table reflow bug. Under certain conditions, the block code can either return the correct or incorrect desired size. As a result, the surrounding table can layout properly or improperly. When this happens in tandem, we see the shift (or overlap, depending on the location of the table). One minute the table is okay. The next minute it isn't. The sections of code in nsBlockFrame::Reflow() where the problem comes from can be sketched structurally as: nsBlockFrame::Reflow() { ... nsIFrame* target; switch (aReflowState.reason) { ... case eReflowReason_Incremental: aReflowState.reflowCommand->GetTarget(target); if (this == target) { [1] reflow with some optimizations ... [2] ComputeFinalSize() and **RETURN** ... } else { [3] reflow with some other optimizations ... } break; ... handle the cases of other reflow reason } [4] do some other common work [5] ComputeFinalSize() ... [6] adjust the metrics to be returned if necessary (eg, if "overflow" to wrap) ... do some other work that rely on the known metrics (e.g., %-based stuff) ... clean up unneeded stuff } So, oversimplifying for the sake of the presentation, we have something like: if (eReflowReason_Incremental == aReflowState.reason) { if (this == target) { ... do this [1,2] else { ... do that [3,4,5,6] } } And the problem is that, depending on the code-paths, the block code returns different metrics. If [6] is included, the metrics are okay. But if the reflow ends without including [6], the metrics can be incorrect. (I guess [6] is critical in this case because it takes care of the "secret" frames that are stacked to embellish the appearance of the GfxText.) So here is the picture: if [6] is on, the table appears okay; if [6] is off, the table shifts. These are the situations that were happening during editing. When the page is first loaded, it is an initial reflow, the code path includes [6] and all is okay. When the first character is typed in, Ender creates a TextNode, which leads to the creation of a nsTextFrame which is the target of the incremental reflow, so "(this == target)" is false in the block reflow code, and we do get to [6]. Then, the second character is typed in, but now the target is the block frame to allow the block to highly optimize the reflow, so "(this == target)" is true. We miss [6], and the shift (or overlap) surface. There is no movement for the other characters because we stay in this erroneous mode. But when we delete, we go back up to the point where the TextNode and nsTextFrame are deleted, and the initial process repeats itself. So the patch consists in including [6] once for all in ComputeFinalSize(). Also the patch fixes an omission that was in [6]. The max-element-size was not kept in sync. This was the reason why a table could curiously have a cell larger than the others. For example, if a table has a column of images of different (unspecified) widths, the cells could be misaligned. (With a narrow content window, this problem can be seen for example at http://www.mozilla.org/projects/mathml/demo/texvsmml.xml -- row #13.)
Nice work, rbs. (And thanks for the lucid explanation of what is going on!) I dug through CVS history, and it looks like troy moved this code over from nsAreaFrame.cpp (in r1.60 of that file). Furthermore, it looks like the bug was present during incremental reflow *there*, as well. I wonder if you should use nsBlockReflowState::UpdateMaximumWidth() and UpdateMaximumElementSize() instead of twiddling them `by hand'?
I had another look. It looks like the code at that stage (in ComputeFinalSize()) is getting set for the return from the reflow, and the code there is more concerned with correctness and is mostly filling variables to be returned rather than updating the internal state. For instance, early in CFS(), there is this snippet which updates aMetrics.mMaximumWidth: 2316 // If we're requested to update our maximum width, then compute it 2317 if (aState.GetFlag(BRS_COMPUTEMAXWIDTH)) { 2318 // We need to add in for the right border/padding 2319 aMetrics.mMaximumWidth = aState.mMaximumWidth + borderPadding.right; 2320 #ifdef NOISY_MAXIMUM_WIDTH 2321 printf("nsBlockFrame::ComputeFinalSize block %p setting aMetrics.mMaximumWidth to %d\n", this, aMetrics.mMaximumWidth); 2322 #endif 2323 } So yes, fiddling with aMetrics afterwards seems like the price to pay to get things right for the caller.
Whiteboard: [nsbeta3-] relnote-devel → [nsbeta3-] relnote-devel [fix in hand]
Ok, assuming you've run this through the regression tests, [r/sr]=waterson, whichever helps.
Just ran the block regression tests. There were 24 cases of mismatch, with three cases of "bbox mismatch" (involving a child tableFrame, viewportFrame, and blockFrame). All the other remaining cases were "state mismatch" happening with child GFX widgets. In principle the patch should be fixing the problems of shift/jump/overlap that have been observed in the incremental reflow of tables in connection with static (i.e., not necessarily floating) text-inputs and images. So this is something that QA should check out. I am including the list of mismatches in cases unforseen regressions similar to these are reported. 1. file:///s:/mozilla/layout/html/tests/block/bugs/4515.html frame bbox mismatch: 0,0,8925,4350 vs. 0,0,9060,4350 Node 1: ScrollPortFrame 2. file:///s:/mozilla/layout/html/tests/block/bugs/5196.html frame bbox mismatch: 120,120,8940,555 vs. 120,120,8940,91 Node 1: Block 3. file:///s:/mozilla/layout/html/tests/block/bugs/5537.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 4. file:///s:/mozilla/layout/html/tests/block/bugs/5847.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 5. file:///s:/mozilla/layout/html/tests/block/bugs/8438.html frame state mismatch: 0x3014 vs. 0x2014 Node 1: Viewport 6. file:///s:/mozilla/layout/html/tests/block/bugs/8905.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 7. file:///s:/mozilla/layout/html/tests/block/bugs/13196.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 8. file:///s:/mozilla/layout/html/tests/block/bugs/14118-b.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 9. file:///s:/mozilla/layout/html/tests/block/bugs/14489.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 10. file:///s:/mozilla/layout/html/tests/block/bugs/15882-b.html frame bbox mismatch: 0,1620,3375,765 vs. 0,1620,3525,765 Node 1: TableOuter 11. file:///s:/mozilla/layout/html/tests/block/bugs/16173.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 12. file:///s:/mozilla/layout/html/tests/block/bugs/16580.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 13. file:///s:/mozilla/layout/html/tests/block/bugs/17054.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 14. file:///s:/mozilla/layout/html/tests/block/bugs/17130-a.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 15. file:///s:/mozilla/layout/html/tests/block/bugs/17636.html frame state mismatch: 0x2014 vs. 0x3014 Node 1: Viewport 16. file:///s:/mozilla/layout/html/tests/block/bugs/17844.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 17. file:///s:/mozilla/layout/html/tests/block/bugs/18445.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 18. file:///s:/mozilla/layout/html/tests/block/bugs/18445_1.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 20. file:///s:/mozilla/layout/html/tests/block/bugs/18445_2.html frame state mismatch: 0x24 vs. 0xa4 Node 1: ButtonControl 21. file:///s:/mozilla/layout/html/tests/block/bugs/18445_3.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 22. file:///s:/mozilla/layout/html/tests/block/bugs/44709.html frame state mismatch: 0x20802024 vs. 0x208020a4 Node 1: SliderFrame 23. file:///s:/mozilla/layout/html/tests/block/bugs/47456.html frame state mismatch: 0x2000 vs. 0x2080 Node 1: Canvas 24. file:///s:/mozilla/layout/html/tests/block/bugs/58652.html frame state mismatch: 0x20c020a4 vs. 0x20c02024 Node 1: SliderFrame
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Patch checked-in. Resolving as FIXED.
This fix caused a regression (bug 67796)
rbs, you should also run the table regression tests when making block changes. They may have caught this regression and certainly would catch other potential regressions. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Re-closing to get it off the radars. The regression is now identified and understood. A proposed fix that doesn't undo this fix is under consideration. The relevant investigation and testings are going on on bug 67796 which is not yet crowded with many things.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified on build 2001071508 os:win95
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: