Last Comment Bug 215857 - {inc}percentage-width blocks inside table cells can make cells too big
: {inc}percentage-width blocks inside table cells can make cells too big
: qawanted, regression, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 All
: P1 normal with 13 votes (vote)
: ---
Assigned To: layout
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
: 107873 217049 219541 220028 220502 222641 226320 227670 (view as bug list)
Depends on: 217590
Blocks: 217369 220247 223906 224469 224949
  Show dependency treegraph
Reported: 2003-08-11 13:31 PDT by Federico Carbonell
Modified: 2007-12-10 11:49 PST (History)
27 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

screenshot from win2k and todays nightly (42.88 KB, image/gif)
2003-08-11 14:06 PDT, Matthias Versen [:Matti]
no flags Details
testcase (1002 bytes, text/html)
2003-08-11 20:59 PDT, Andrew Schultz
no flags Details
testcase using JS trick (510 bytes, text/html)
2003-09-06 07:55 PDT, Andrew Schultz
no flags Details
testcase without hr (549 bytes, text/html)
2003-09-08 08:23 PDT, Bernd
no flags Details
reflow log (8.59 KB, text/plain)
2003-09-08 08:29 PDT, Bernd
no flags Details
Why it happened on one site in particular, which didn't get fixed by refreshing, etc (1.30 KB, text/plain)
2003-11-09 05:58 PST, shadowlord13_1
no flags Details
,testcase without hr but with a table (585 bytes, text/html)
2003-11-16 01:06 PST, Bernd
no flags Details
So like this? (1014 bytes, patch)
2003-11-16 11:38 PST, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review
patch that makes the regression tests happy (1.52 KB, patch)
2003-11-21 08:23 PST, Bernd
no flags Details | Diff | Splinter Review
patch to make HaveAutoWidth and !HaveAutoWidth generate the same m-e-w for % widths (2.10 KB, patch)
2003-11-22 22:17 PST, David Baron :dbaron: ⌚️UTC-8
bernd_mozilla: review+
bzbarsky: superreview+
brendan: approval1.6b+
Details | Diff | Splinter Review

Description Federico Carbonell 2003-08-11 13:31:40 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030810
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030810

The page in is not displayed correctly. The main contents
are displayed with excessive space to the left. It looks like an improper
rendering of the html <table> tag.

Reproducible: Always

Steps to Reproduce:
1. Go to

Actual Results:  
The page actually looks wrong with the main contents showing excessive blank
spaces to the left, making necessary to scroll to the right to see content. When
I refresh the page, the problem goes away. It happens when I load the page for
the first time.

Expected Results:  
Display the page with the main contents centered without the excessive blank
spaces on the left.

This problem does not crash Mozilla.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2003-08-11 13:49:58 PDT
Worskforme, linux trunk build 2003-08-11-05
Comment 2 Matthias Versen [:Matti] 2003-08-11 14:06:39 PDT
Created attachment 129610 [details]
screenshot from win2k and todays nightly
Comment 3 Matthias Versen [:Matti] 2003-08-11 14:07:32 PDT
a reload fixed this
Comment 4 Andrew Schultz 2003-08-11 20:59:17 PDT
Created attachment 129637 [details]

testcase usually shows the bug with linux trunk 2003081005, less so with
previous builds.  the left cell is too wide (wider than the right cell). 
reloading fixes it.

I served this up with a php script that delayed a bit between each line. 
bugzilla might provide enough delay, maybe not.
Comment 5 Andrew Schultz 2003-08-11 21:18:01 PDT
this regressed between linux trunk 2003072905 and 2003073005, apparently bug 38370
earlier builds do not exhibit the bug, even in standards mode.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2003-09-06 07:38:41 PDT
Andrew, could you possibly narrow down where the layout needs to happen in
mid-load?  See
for a technique for doing that....
Comment 7 Andrew Schultz 2003-09-06 07:55:01 PDT
Created attachment 130994 [details]
testcase using JS trick

using the JS trick bz pointed out, this is simpler and 100% reproducible,
without resorting to php tricks.
the left cell should be small (135 pixels) but it's wider than the right cell.
Comment 8 Bernd 2003-09-08 08:23:01 PDT
Created attachment 131075 [details]
testcase without hr
Comment 9 Bernd 2003-09-08 08:29:05 PDT
Created attachment 131076 [details]
reflow log

This error is not new, it only was made visible due to hr checkin. See the new
testcase. The issue here is that on dirty reflow the block code returns the
wrong MEW.
Lets mind execute the test case:
On the initial run, due to the break point the table will have only one cell.
The breakpoint excludes the div and the second cell. The cell has a specified
fixed width but the table needs to redistribute the remaining space to this
cell so it will grow to fill the table. On the second run the div will be added
to the table cell. The cell has the computed width as large as necessary to
fill the table. The inner div computes easily the nessary width and return also
this width as the MEW. On the third pass the second cell is added to the row.
This has a side effect on the first cell with the div. The first cell sees a
dirty reflow. More than this it sees a unconstrained computed width and it
requires the childs to give back the MEW. Now the block code marks the text
lines as dirty and reflows them but it does not reflow the inner block and
reports back the old but now incorrect MEW. The first table cell has now a
specified width but a large MEW. This requirement influences the table layout
strategy and the final resize reflow gives the wrong shape.
Comment 10 David Baron :dbaron: ⌚️UTC-8 2003-09-08 08:30:20 PDT
This wouldn't have been fixed by the checkin for bug 209066, would it?
Comment 11 Bernd 2003-09-08 08:36:10 PDT
no it would not have been fixed as the div has no margins around it specified
Comment 12 Andrew Schultz 2003-09-18 07:51:13 PDT
*** Bug 219541 has been marked as a duplicate of this bug. ***
Comment 13 Andrew Schultz 2003-09-24 20:25:22 PDT
*** Bug 217049 has been marked as a duplicate of this bug. ***
Comment 14 Hussam Al-Tayeb 2003-09-25 01:10:08 PDT
in bug 217049 , somebody mentioned that this bug happens only in and which is wrong since it happens on many websites. 
i also noticed that it tendes to happen more to people who are behind a firewall
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2003-09-25 14:48:11 PDT
*** Bug 220028 has been marked as a duplicate of this bug. ***
Comment 17 Hussam Al-Tayeb 2003-09-27 02:05:16 PDT
this could be a dublicate of 217369
Comment 18 David Baron :dbaron: ⌚️UTC-8 2003-09-27 16:02:19 PDT
*** Bug 220502 has been marked as a duplicate of this bug. ***
Comment 19 Ewok 2003-10-02 03:55:47 PDT
just discovered something new.  i am using aebrahims SSE2 build from 29th sept.
 Just tried selecting the orbitz expanded them on and it absolutely
refuses to display properly, regardless of refreshing or not.  It has the same
problem with everything being off the right of the screen too much, but it
absolutely wll not render properly no matter what i do, unless i choose one of
the other themes (all the others are able to display it properly, if not first
time, then after a refresh).

The other thing is that saving the page to disk and loading it from there, for
the first time ever, still exhibits the problem.  Before it had ALWAYS loaded
perfectly first time form disk, but this specific page refuses to render
properly at all.  It may change when the contents of the page changes so i have
saved the copy i have on disk if anyone wants it for testing.
Comment 20 Hussam Al-Tayeb 2003-10-02 10:06:18 PDT
That's true, refreshing stopped helping in .7+ when viewing
Comment 21 Ewok 2003-10-03 05:21:38 PDT
Just checked ntfs again.  It seems that when using the ekko expanded theme, then
clicking some of the links at the top, when it renders wrongly (most of the time
but not all the time), a refresh DOES fix it.

however now when using the orbitz expanded theme, doing the same thing, a
refresh does NOT fix it, and it renders wrongly EVERY time you click ANY of the
links at the top, but NOT when you first load the page.

Also I havent actually seen adslguide render wrongly at all since ive been using
this 29th sept build, but ntfs and flexbeta obviously still do.
Comment 22 David Baron :dbaron: ⌚️UTC-8 2003-10-03 09:23:55 PDT
Knowing exactly what causes and fixes this bug isn't really helpful.  We have a
simplified testcase, and all you're telling us is numerous different ways to
cause the same pattern of incremental reflows.
Comment 23 Hussam Al-Tayeb 2003-10-03 10:10:51 PDT
Re: Knowing exactly what causes and fixes this bug isn't really helpful.

If so, any other way to find the cause of this bug? That's because I noticed
that this bug is still unassigned. Anyway, in terms of programming, can this bug
be solved by a simple fix or will it require a big change in the code?
(especially since it also showed up in mozilla 1.5b and newer builds)which could
mean that it is not a firebird specific bug?
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2003-10-03 14:21:58 PDT
> If so, any other way to find the cause of this bug?

The minimal testcase is a lot better at demonstrating that cause than any list
of URLs which would just reduce to the same testcase.

And no, this is not firebird-specific -- that's why it's in the "Browser" product.
Comment 25 Joe Blough 2003-10-15 13:45:44 PDT
Is this the same issue that causes Freshmeat to render incorrectly (can't see
the right sidebar) if the browser is sized too thin?
Comment 26 Michael Moulton 2003-10-23 09:14:23 PDT
Seems to occur on as well.
Comment 27 Marek Stępień [:marcoos, inactive] 2003-10-27 13:31:55 PST
I've got an other workaround for this. I even created a bookmarklet:


The same code can be put into onload, so there's no need to search which table
cell causes the layout to
Comment 28 Marek Stępień [:marcoos, inactive] 2003-10-27 13:33:06 PST
...causes the layout to behave strangely.

(Bugzilla ate my comment ;))
Comment 29 Hussam Al-Tayeb 2003-11-09 04:34:17 PST
Test case (observation):
1. open
2. refresh a couple of times untill it renders correctly
3. increase the font a lot using ctrl ++ , untill there are horizontal scrollbars
4. Decrease the font again using ctrl -- , it will not change back to the
original "font size"   (before step 3) and the scrollbars will remain. The page
will be messed up again.
Comment 30 Steve 2003-11-09 05:14:49 PST
I can not reproduce the render problem it works fine for me on
2 computers.
Comment 31 shadowlord13_1 2003-11-09 05:58:40 PST
Created attachment 135119 [details]
Why it happened on one site in particular, which didn't get fixed by refreshing, etc

Also, this WOULD include a testcase, if SourceForge hadn't removed the
WIDTH=100% line from the project news export pages, which was apparently
conflicting with the WIDTH=70% for the part of the table said project news
export page was being displayed in.
Comment 32 Hussam Al-Tayeb 2003-11-09 06:33:32 PST
Re: Comment #30
That's probably because when you have a fast connection, the problem does not
seem to happen very often. In my case,the network traffic is big so this problem
seems to happen a lot.
Comment 33 Alexander 'Chewie' Hirzel 2003-11-10 10:22:48 PST
If it helps, this page appears to have the exact same problem:

This may also affect other pages on that site,
but I didn't really look around much.
Comment 34 Bernd 2003-11-10 22:23:28 PST
Dear commenters, 

especially those who added comment 25-33, could you please stop spamming this
bug. Please read carefully comment 22. If comment 22 is not explicit enough, I
will try to make it more obvious. Layout bugs are debugged with reduced
testcases like attachment 131075 [details]. There is even a first guess of a code level
explanation in comment 9. This bug needs a patch or may be a different code
level explanation. But it certainly does not need new urls.

Please no new URL's, no "if I change this it goes away", no "if I reload it goes

Add a patch, thats all what is needed.
Comment 35 Bernd 2003-11-16 00:59:59 PST
When the HR Frame did go away (bug 38370) the following code went the dodo way:

-  // HR's do not impact the max-element-width, unless a width is
-  // specified otherwise tables behave badly. This makes sense -- they
-  // are springy.
-  if (aDesiredSize.mComputeMEW) {
-    if (NS_UNCONSTRAINEDSIZE != aReflowState.mComputedWidth) {
-      nsStyleUnit widthUnit = aReflowState.mStylePosition->mWidth.GetUnit();
-      if ((eStyleUnit_Percent == widthUnit) || 
-          (eStyleUnit_Auto == widthUnit)) {
-        // When the HR is using an 'auto' or percentage width, make sure it
-        // remains springy.
-        aDesiredSize.mMaxElementWidth = onePixel;
-        aDesiredSize.width = PR_MAX(aDesiredSize.width, onePixel);
-      }
-      else {
-        aDesiredSize.mMaxElementWidth = aReflowState.mComputedWidth;
-      }
-    }
-    else {
-      aDesiredSize.mMaxElementWidth = onePixel;
-      aDesiredSize.width = PR_MAX(aDesiredSize.width, onePixel);
-    }
-    NS_ASSERTION(aDesiredSize.mMaxElementWidth <= aDesiredSize.width,
-                 "bad max-element-width");
-  }

What blocks currently do is
// When style defines the width use it for the max-element-width
// because we can't shrink any smaller.

As one can see from the testcase this is not always true.
Comment 36 Bernd 2003-11-16 01:06:53 PST
Created attachment 135631 [details]
,testcase without hr but with a table
Comment 37 Boris Zbarsky [:bz] (still a bit busy) 2003-11-16 01:10:47 PST
Bernd, is HaveAutoWidth() testing false in the testcases in this bug?  (see
Comment 38 Bernd 2003-11-16 08:30:37 PST
On the initial reflow it returns PR_TRUE as the computed width is
NS_UNCONSTRAINEDSIZE. On the resize reflow it returns of course PR_FALSE. The
problem with the block code is that it assumes that if the block has a computed
width and the style is percentage based, that the specified width of the
containing block is equal to currently computed width of the containing block.
For tables this is not true. The width specs for table cells are rather
min-width's. If one looks at the testcase without hr, the table cell has a
specified width of 135px and the table cell has spec. width of 766. Due to the
breakpoints the second cell is first not seen so while the specified width is
135px the computed width is 766. Now the computed size of the div should be
766*0.9 but the MEW should at maximum be 135 * 0.9. However the inner div can be
shrinked down to borderpadding + content so one could also argue that its
minimal size could also be borderpadding as it is empty. This is what the HR has
previously done and what tables currently report as MEW.
Comment 39 Boris Zbarsky [:bz] (still a bit busy) 2003-11-16 11:38:25 PST
Created attachment 135670 [details] [diff] [review]
So like this?

This just adjusts HaveAutoWidth to be a little more likely to report "yes".
Certainly fixes the testcases in this bug...  I guess we should run the
regression tests with this sorta change, eh?  ;)
Comment 40 Bernd 2003-11-16 12:33:54 PST
Renaming the function to cover better the content would probably be a good idea
and ehm ... you will need a review from dbaron for this and he likes this kind
of patches ;-)
Comment 41 Boris Zbarsky [:bz] (still a bit busy) 2003-11-16 13:09:51 PST
Heh.  Well, all of that code looks pretty bogus to me, really... ;)
Comment 42 Ewok 2003-11-16 13:47:13 PST
just applied this patch to a nightly i just made and can confirm it solves the
problem on all of the sites that i previously had problems with.  nice.
Comment 43 Boris Zbarsky [:bz] (still a bit busy) 2003-11-16 14:29:23 PST
Comment on attachment 135670 [details] [diff] [review]
So like this?

OK, this is no good.  It makes float sizing all unhappy if they have percentage
widths.  See:
(float in second div too narrow)
(second and third float should have equal width)
ml (same)
(floats on left too narrow)

etc, etc. (all sorts of regression test failures).
Comment 44 Bernd 2003-11-16 23:15:32 PST
Boris, these failures show only that there is no easy solution, especially as
the HR needed several reflow hacks to work somehow properly. IMHO this bug
should waite for dbaron's reflow split up, where the MEW will be computed in a
specialized call chain. There the table width specs as min-width specs can be
handled. Everything else will result in a couple of unmaintanable hacks, like
stack crawl up. And your time is to valuable for us to go this path.
Comment 45 Boris Zbarsky [:bz] (still a bit busy) 2003-11-16 23:27:49 PST
Hey, sounds like a plan to me.  ;)  I'd already deprioritized it once I figured
out that the solution is Hard.  ;)
Comment 46 Jon Henry 2003-11-20 07:09:33 PST
*** Bug 226320 has been marked as a duplicate of this bug. ***
Comment 47 Bernd 2003-11-21 08:23:11 PST
Created attachment 136052 [details] [diff] [review]
patch that makes the regression tests happy
Comment 48 David Baron :dbaron: ⌚️UTC-8 2003-11-21 10:50:21 PST
Comment on attachment 136052 [details] [diff] [review]
patch that makes the regression tests happy

This looks fine to me if the regresssion tests are happy, although I'm a bit
puzzled why bz's patch made things narrower than they were before and this
patch doesn't.	(I also don't think that what this whole chunk of code does
fits the logic of what it should be doing.)

But please wrap the comments at less than 80 characters, and:
+    const nsStylePosition* pos = GetStylePosition();
+    if (eStyleUnit_Percent == pos->mWidth.GetUnit()) {

could be written as:

+    if (GetStylePosition()->mWidth.GetUnit() == eStyleUnit_Percent) {
Comment 49 David Baron :dbaron: ⌚️UTC-8 2003-11-21 10:52:00 PST
Actually, I'm not sure I like this approach.  I'll write some tests and get back
to you later today...
Comment 50 David Baron :dbaron: ⌚️UTC-8 2003-11-22 22:06:12 PST
Comment on attachment 136052 [details] [diff] [review]
patch that makes the regression tests happy

I think bernd's approach is basically the right one -- this is one of the cases
where we get different max-element-width results when we reflow with a
constrained or unconstrained width, so I think this is the right place to test
for percentages in order to fix the bug.

I think I prefer the idea that we should be using the content
max-element-width, though, even though that isn't exactly right...

I admit that isn't exactly what IE/Windows is doing (See ), but I think we'll end up with
closer results that way, since we won't produce overflow from table cells
unless the width is specified as over 100%.

Furthermore, I prefer that idea since, for the unconstrained reflow, we're
likely to follow the second codepath rather than the first, so we should make
the two codepaths match for the percentage width case, since that case will
take one some of the time and the other some of the time.
Comment 51 David Baron :dbaron: ⌚️UTC-8 2003-11-22 22:17:15 PST
Created attachment 136149 [details] [diff] [review]
patch to make HaveAutoWidth and !HaveAutoWidth generate the same m-e-w for % widths

This is what I was describing in my previous comment
Comment 52 David Baron :dbaron: ⌚️UTC-8 2003-11-22 22:21:52 PST
Comment on attachment 136052 [details] [diff] [review]
patch that makes the regression tests happy

I suspect this (Bernd's) patch will cause some regressions, but since it's only
touching what I think is an incremental reflow case (computing the m-e-w while
reflowing with a fixed containing block width -- i.e., no need to determine
max-width), I suspect they won't show up in the regression tests since they'll
only show up on incremental reflows.

I really should test my assumption that the fun of nsHTMLReflowState is causing
us to follow the HaveAutoWidth codepath for the incremental m-e-w with
constrained width case...
Comment 53 David Baron :dbaron: ⌚️UTC-8 2003-11-22 22:28:37 PST
Also, if you want to understand what HaveAutoWidth is doing (logically), it
might help to look at how it simplifies in the changes in bug 205790 (which are
the result of simplifying the logic after removing eStyleUnit_Inherit).  I
didn't really understand what was going on here until I made those changes.
Comment 54 David Baron :dbaron: ⌚️UTC-8 2003-11-23 00:32:18 PST
Comment on attachment 136149 [details] [diff] [review]
patch to make HaveAutoWidth and !HaveAutoWidth generate the same m-e-w for % widths

I ran through the regression tests once with a printf in the new codepath (the
% case), and  the new codepath was only hit in a single test
(formctls/bugs/bug42481.html),	so this change isn't really tested by the
regression tests...
Comment 55 Boris Zbarsky [:bz] (still a bit busy) 2003-11-23 13:46:31 PST
*** Bug 128601 has been marked as a duplicate of this bug. ***
Comment 56 Boris Zbarsky [:bz] (still a bit busy) 2003-11-23 19:15:48 PST
Comment on attachment 136149 [details] [diff] [review]
patch to make HaveAutoWidth and !HaveAutoWidth generate the same m-e-w for % widths

sr=bzbarsky... we should really refactor this code.  :(
Comment 57 David Baron :dbaron: ⌚️UTC-8 2003-11-23 19:38:54 PST
Comment on attachment 136149 [details] [diff] [review]
patch to make HaveAutoWidth and !HaveAutoWidth generate the same m-e-w for % widths

Requesting approval for what's probably our most common incremental reflow bug.
Comment 58 Brendan Eich [:brendan] 2003-11-24 10:27:59 PST
Comment on attachment 136149 [details] [diff] [review]
patch to make HaveAutoWidth and !HaveAutoWidth generate the same m-e-w for % widths for 1.6b.

Comment 59 David Baron :dbaron: ⌚️UTC-8 2003-11-24 11:49:57 PST
Fix checked in to trunk, 2003-11-24 11:48 -0800.
Comment 60 Boris Zbarsky [:bz] (still a bit busy) 2003-11-24 12:50:43 PST
Probably worth going through the dependencies of this bug and bug 217590 and
seeing which ones went away....
Comment 61 David Baron :dbaron: ⌚️UTC-8 2003-11-24 12:54:30 PST
I'm already doing a pair of builds for that purpose.
Comment 62 Oliver Klee 2003-11-24 14:19:40 PST
Does this affect bug 224469 as well?
Comment 63 amano 2003-11-24 17:18:44 PST
Now it works for me :))

Bug 217590 and bug 224469 seem to be fixed as well!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031124
Firebird/0.7+ (Nova: MNG,DOMi)

Comment 64 Hussam Al-Tayeb 2003-11-25 01:34:45 PST
I'm using the official 20031124 nightly on windows xpsp1 (new directory and new
profile) and I still see this bug on
Comment 65 Hussam Al-Tayeb 2003-11-25 01:48:28 PST
Re: Comment #64
Using firebird and not mozilla.
Comment 66 Michael Lefevre 2003-11-25 02:45:31 PST
Hussam: that's to be expected - this was checked in (dbaron helpfully gave the
time in comment 59) at 2003-11-24 11:48 -0800.  The Firebird Windows
build was made some time around 2003-11-24 08:00 -0800, so the change would not
be in that build.
Comment 67 Hussam Al-Tayeb 2003-11-25 03:43:17 PST
Re, Comment #66. Thank you for your prompt reply.Anyway I was able to find a
newer build which contained the fix. So Excellent Work people!
You see I live in different time zone so I get mixed up about those things.
Comment 68 Boris Zbarsky [:bz] (still a bit busy) 2003-12-06 15:35:20 PST
*** Bug 227670 has been marked as a duplicate of this bug. ***
Comment 69 Julien Muchembled 2003-12-10 14:00:01 PST
I don't understand.
Related bugs (like 217590, 217369...) are still opened. Does it mean this bug is
different and the fix would only resolve a part of the problem ?
I thought it was fixed, but today, I've been very surprised to see that :

url to the page :
Comment 70 Ewok 2003-12-10 14:17:53 PST
it doesnt appear to be completely fixed as still shows up too 
wide sometimes, but it has fixed the majority of them so i think these other 
sites may be a different problem.
Comment 71 Olivier Cahagne 2003-12-10 14:30:58 PST
*** Bug 222641 has been marked as a duplicate of this bug. ***
Comment 72 Boris Zbarsky [:bz] (still a bit busy) 2003-12-10 17:28:10 PST
Frankly, the other bugs are open because no one has gone through and checked
whether the problem still appears with those testcases and sites....  If someone
could, that would be nice.  Please do NOT mark this bug verified until you have
done that.
Comment 73 Hussam Al-Tayeb 2003-12-10 22:24:00 PST
re Comment #72 , correct since although this one is fixed, bug 217369 is still
not fixed.
Comment 74 Hussam Al-Tayeb 2003-12-10 22:26:26 PST
the url in bug 217369 still displays incorrectly
Comment 75 David Baron :dbaron: ⌚️UTC-8 2004-01-20 11:53:02 PST
It's nice to realize that I wrote what was essentially the patch that fixed this
bug a year and a half before this bug was filed (on bug 107873) and let Alex
Savulov convince me not to check it in, even though it was clearly correct,
because it caused some sort of obscure regression.
Comment 76 David Baron :dbaron: ⌚️UTC-8 2004-01-20 11:53:42 PST
*** Bug 107873 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.