183351 - XML PrettyPrinting fails to always properly collapse tags

Status: NEW

(Core :: Layout, defect, P4)

Description

[Licinio Alves]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

Viewing XML files (without stylesheets), allows for collapsing and expanding of
tags, and their nexted tags.  Following tags then shift up taking up the space
of expanded tags and their subtags.  If a line is too long relative to the width
of the Mozilla browser window, the subsequent tags are shifted up on the page to
fill in the blank lines that are left from the preceeding tag that is collapsed.

e.g.
<?xml version="1.0"?>
<Unit>
	<OrderList CustPOC="Joseph Q. Smith" CustTele="[phone]" MSN="111"
Idxxxxxx="555" ShipAddress1="MyHouse, Town, USA">
                <Item> A </Item>
                <Item> B </Item>
                <Item> C </Item>
	</OrderList>

	<PartList>
		<Part> 100 </Part>
		<Part> 101 </Part>
		<Part> 102 </Part>
	</PartList>
</Unit>


Reproducible: Always

Steps to Reproduce:
1. Save above xml text to test.xml
2. Resize Mozilla window to half of screen width
3. Load test.xml
4. Collapse the OrderList tag (click on '-')

Actual Results:  
OrderList tag is collapsed leaving blank lines after it, and before PartList.

Expected Results:  
The PartList tag should have moved up on the page into where the blank lines are.

Repeating steps 2 and 3, with the Mozilla window maximized, works properly.

Comment 1

[Licinio Alves]

Correction:

If a line is too long relative to the width of the Mozilla browser window, the
subsequent tags are NOT shifted up on the page to fill in the blank lines that
are left from the preceeding tag that is collapsed.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

sicking's

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, i noticed this while implementing the prettyprint. The problem is somewhere
in layout so i'll assign to there

Comment 4

[Hixie (not reading bugmail)]

um, we're gonna need a smaller testcase :-)

sicking: Any chance you could create a test version of the prettyprinter output
that doesn't involve XBL and XSLT?

Comment 5

[Boris Zbarsky [:bzbarsky]]

To sicking so we actually end up with a testcase.

Comment 6

[Axel Hecht]

Attachment: xhtml and xul one-file testcase

This is a testcase that may or may not be related. Didn't have the guts to 
reproduce the current table driven scenario, but this one with a xul:hbox
does expose a similar behaviour.
Relevant to this bug, as I'm moving from xhtml:table to xul:hbox as part of 
bug 231925.
If I remove the xul:hbox it behaves like expected. I bet that doing this inside

a td as the current pretty-printer does is somewhat similar. I don't think that

the spans around the div matter.
The xbl stuff is whacked around by the two buttons, which set style.display of
the dif to either none or block.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually, most likly the XUL problem is something different from the originally
reported problem. Isn't the box-layout code very different from the frame-layout
one?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.