Closed Bug 101216 Opened 19 years ago Closed 16 years ago

[PFM]<nobr> was incorrectly inherited, now just assertions

Categories

(Core :: DOM: HTML Parser, defect, minor)

x86
All
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jesup, Assigned: dbaron)

References

()

Details

(Keywords: compat)

Moilla 2001091403

This page lays out extremely poorly; I suspect the reason is due to CSS that's
non-compliant with the standards (i.e. IE and maybe ns4.x only).  The reason I
bring it up is because (if it is not a bug in Mozilla, and not something to add
to quirks) it may be something we should evangelize with USA Today.

There are all sorts of layout problems with this page - ultra-wide columns, text
overlaying a sidebar, a sidebar on top of text, etc.

Probably a simple inspection by someone who knows CSS will show they're all
Evang bugs, but I can't be sure.

One of the several problems is with an absolutely-positioned box overlaying the
main text; in the source for the page it has this:

<div id=AdLayer style="TOP: 15px; LEFT: 620px; WIDTH: 150px; POSITION: absolute">

However, it's also possible they're relying on stuff like this, though I suspect
this is supposed to provide minimums:

<!-- ######################################################################### -->
<!-- RULES TO MAINTAIN COLUMN WIDTHS                                           -->
<!-- ######################################################################### -->
<tr><td WIDTH="10"  ALIGN="LEFT" VALIGN="TOP"><hr WIDTH="10"  SIZE="1" noshade></td>
<td WIDTH="229" ALIGN="LEFT" VALIGN="TOP" COLSPAN="1"><hr WIDTH="229" SIZE="1"
noshade></td>
<td WIDTH="229" ALIGN="LEFT" VALIGN="TOP" COLSPAN="1"><hr WIDTH="229" SIZE="1"
noshade></td></tr>
It probably doesn't help that they've put the <link>s to their stylesheets in
the body of the page.  Changing component to Layout.
Component: Style System → Layout
Whiteboard: Evang?
Oops.  And reassigning.
Assignee: dbaron → attinasi
QA Contact: ian → petersen
The whole page is inside a <NOBR>. Remove that tag at the beginning of the page
and it lays out correctly. IE6 and Opera5 has no problems with the page as is,
perhaps they auto-close <NOBR> when seeing <TABLE> which is the following tag?
More likely <nobr> shouldn't apply to inside the table (much like <font> on the
outside doesn't apply to inside a <table>).

Confirmed: if I add this to quirks (or a user style), the page lays out
correctly.

nobr {
  white-space: normal;
}

I'm guessing (at least in quirks, and quite possibly in strict) that the
white-space attribute should not be inherited by a table.

Changing subject.  Component might be style system, but I'm not sure so I'm
leaving it.
Summary: Serious layout problems: text over graphics, bad column widths → <nobr> is incorrectly inherited by tables
Whiteboard: Evang?
As Mats pointed out, <TABLE> should close <NOBR>.  CCd Harish...
Nominating for 0.9.6.  I'd assume this is a fairly simple issue to fix.
Keywords: mozilla0.9.6
http://www.usatoday.com/life/cyber/tech/cti726.htm
apart from a menu the page is empty - same bug?
Reassigning to Harish since the solution seems to be:
 <TABLE> should close <NOBR>

Assignee: attinasi → harishd
->parser
Component: Layout → Parser
Keywords: compat
Changing nomination keyword.
Keywords: mozilla0.9.6mozilla1.0
Tanu is working on this. 
Assignee: harishd → tmutreja
I tried accessing the given URL: 
http://www.usatoday.com/life/cyber/ccarch/cced044.htm

I could see no difference in it's display on IE5.X, Netscape 6.2, Netscape 4.76 
and Mozilla Dec20'th build . Page looks fine except that it has a blank part on 
the right but that is common for all the browsers.

As the above comments state, page contains <TABLE> inside <NOBR> but I see no 
difference on removing it also.

As mentioned above, start of <TABLE>should close <NOBR>. Is this an HTML 
specification? I tried closing this tag before <table> starts and no 
difference again.

In case there is an specification for closing <NOBR> before <TABLE>, 
do we need to open <NOBR> again (to keep it's effect for the rest of 
the document) after the <TABLE> is closed?

Please provide more information for reproducing it.
I don't see the bug today, but the problem is that sites like this often change
their boilerplate, so there's no guarantee it's the same.  However, it still
does have a <nobr><table> at the front, so it may be.  It needs to be tried with
an old mozilla version to verify.  Several people saw this problem when it was
reported.
Recommending it to be marked as "WORKSFORME". 
I retested the URL with mozilla 2001113003 win32, and the problem is still there
in that (old) build.

In a build done today, it works, but I get these assertions (and more of the
same).  I suspect that dbaron's "vertical state recovery" patch may have fixed
this bug.  dbaron?  Leaving open for these assertions, or until it's decided
they're irrelevant.  Reassigning to dbaron.  New summary, severity to minor.


###!!! Break: at file nsFrameManager.cpp, line 985
###!!! ASSERTION: frame was not removed from primary frame map beforedestruction
or was readded to map after being removed: '!PL_DHASH_ENTRY_IS_BUSY(entry) ||
entry->frame != aFrame', file nsFrameManager.cpp, line 985
###!!! Break: at file nsFrameManager.cpp, line 985
###!!! ASSERTION: expected to be inline incremental reflow:
'aState.GetFlag(BRS_ISINLINEINCRREFLOW)', file nsBlockFrame.cpp, line 2527
###!!! Break: at file nsBlockFrame.cpp, line 2527
###!!! ASSERTION: expected to be inline incremental reflow:
'aState.GetFlag(BRS_ISINLINEINCRREFLOW)', file nsBlockFrame.cpp, line 2527
###!!! Break: at file nsBlockFrame.cpp, line 2527
###!!! ASSERTION: expected to be inline incremental reflow:
'aState.GetFlag(BRS_ISINLINEINCRREFLOW)', file nsBlockFrame.cpp, line 2527
###!!! Break: at file nsBlockFrame.cpp, line 2527
###!!! ASSERTION: this doesn't do anything: 'NS_UNCONSTRAINEDSIZE !=
aReflowState.availableWidth', file nsTableFrame.cpp, line 1962
Assignee: tmutreja → dbaron
Severity: normal → minor
Summary: <nobr> is incorrectly inherited by tables → <nobr> was incorrectly inherited, now just assertions
###!!! Break: at file nsFrameManager.cpp, line 985
###!!! ASSERTION: frame was not removed from primary frame map beforedestruction
or was readded to map after being removed: '!PL_DHASH_ENTRY_IS_BUSY(entry) ||
entry->frame != aFrame', file nsFrameManager.cpp, line 985

... means "likely to crash".  That's serious.
The assertion could be related to bug 117703.
Adding myself to the CC list.
Marking bugs dealing with re-addition to the primary frame map with [PFM].
Summary: <nobr> was incorrectly inherited, now just assertions → [PFM]<nobr> was incorrectly inherited, now just assertions
What's the status of this bug?  I notice that no real activity has been logged
for several months, and I still see the problem (or a very similar one) in Moz
1.0 / Win2k for the URL http://www.usatoday.com/life/lfront.htm

Is it just a lower priority, or has this bug been forgotten?
WFM, 2002-08-24-04 trunk Linux
WFM, 2002-08-24-04 trunk Windows 2000

Also tried a August-ish debug build and didn't see any assertions.
assuming wfm and resolving.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
I filed bug 233743 on the assertions.
You need to log in before you can comment on or make changes to this bug.