XML PrettyPrinting fails to always properly collapse tags

NEW
Assigned to

Status

()

Core
Layout
P4
normal
16 years ago
9 years ago

People

(Reporter: Licinio Alves, Assigned: sicking)

Tracking

Trunk
Future
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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="(888)555-5555" 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.
(Reporter)

Comment 1

16 years ago
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.
sicking's
Assignee: heikki → bugmail
Yes, i noticed this while implementing the prettyprint. The problem is somewhere
in layout so i'll assign to there
Assignee: bugmail → other
Status: UNCONFIRMED → NEW
Component: XML → Layout
Ever confirmed: true
QA Contact: rakeshmishra → ian
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?
Summary: XML PrettyPringing fails to always properly collapse tags → XML PrettyPrinting fails to always properly collapse tags

Updated

16 years ago
Priority: -- → P4
Target Milestone: --- → Future
To sicking so we actually end up with a testcase.
Assignee: other → bugmail

Comment 6

15 years ago
Created attachment 140261 [details]
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.
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?
QA Contact: ian → layout
You need to log in before you can comment on or make changes to this bug.