640390 - HTML transformed from XML through XSLT sometimes displays too wide

Status: NEW

(Core :: XSLT, defect)

Description

[Julian Reschke]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

When opening an XML with XSLT-PI, the generated HTML content sometimes displays too wide (though no horizontal scrollbar).

Resizing the window fixes the layout problem.

Reproducible: Sometimes

Steps to Reproduce:
1. Open http://greenbytes.de/tech/webdav/rfc5988.xml
2. Compare to http://greenbytes.de/tech/webdav/rfc5988.html (which is the static transformation result)

Actual Results:  
Sometimes, the generated content is too wide, as if a wider screen was assumed.

Expected Results:  
XML->XSLT->HTML should display exactly the same way as the static HTML version mentioned above.

This happens only on one of two machines I tried; couldn't figure out the difference yet (both W7SP1).

Comment 1

[Henri Sivonen (:hsivonen)]

Can't reproduce this bug assigning to the right component.

Comment 2

[Julian Reschke]

I just tried with FF4b12 on MacOS, and the effect is the other way round: the display is too small; there's a few inches of white space between the scroll bar and the window border. Again, resizing the window once fixes the problem.

Comment 3

[Julian Reschke]

(In reply to comment #1)
> Can't reproduce this bug assigning to the right component.

I don't see how this could be an XSLT problem; after all, the transformation happens, it's just rendered incorrectly.

I can still reproduce this; is there anything I can do to provide more information?

Comment 4

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

Julian, our XSLT bugzilla component also covers the glue code between the transformation engine and the rest of gecko. Which is likely where this bug lies.

I'm still not seeing the problem though. The only time I get scrollbars is when resizing the window small enough that the <pre>s get too wide. However they have a explicitly declared width of 69em so this seems expected.

Could you try creating a minimized testcase and attach screenshots?

Comment 5

[Julian Reschke]

I can and will, but it will take some time.

Comment 6

[Julian Reschke]

Interesting effect that may have the same cause:

  http://greenbytes.de/tech/tc/xslt/#ft-system-property

The page contains <object/> tags containing transformation results, and for this case, it leaks out of the <object>'s box.

Comment 7

[Julian Reschke]

Attachment: see https://bugzilla.mozilla.org/show_bug.cgi?id=640390#c6

Shows the effect described in comment 6 in FF6/Win7.

Comment 8

[Julian Reschke]

(In reply to Julian Reschke from comment #7)
> Created attachment 560692 [details]
> see https://bugzilla.mozilla.org/show_bug.cgi?id=640390#c6
> 
> Shows the effect described in comment 6 in FF6/Win7.

I can reproduce this with FF6 and 7 on Windows 7, but not with FF6 on MacOs Lion.

Comment 9

[Julian Reschke]

(In reply to Julian Reschke from comment #8)
> ...
> I can reproduce this with FF6 and 7 on Windows 7, but not with FF6 on MacOs
> Lion.

And, on Windows, it requires Zooming in (CTRL-+ twice)

Comment 10

[edA-qa mort-ora-y]

I think the same thing is happening at this page:

http://www.opengl.org/sdk/docs/man/xhtml/glActiveTexture.xml

It just doesn't fit the content to the displayed window. Resizing the window causes it to fix itself.

Note, this is likely related, or a duplicate of 448756.

My Platform is (K)Ubuntu 12.04 64-bit (Firefox 14.0.1)

Comment 12

[C. M. Sperberg-McQueen]

Using Firefox 22 under Mac OS X 10.6.8, I find it hard to detect the problem in some of the examples given (which seem to display correctly), so I offer yet another example:  compare the XML and HTML versions of

  http://blackmesatech.com/2013/07/alloy/index.xml
  http://blackmesatech.com/2013/07/alloy/index.html

The behavior I expect is that they should look substantially the same; the behavior I observe is:

1 The XML version, processed in-browser by XSLT, is formatted for a window somewhat wider than the current window settings.

2 No horizontal scroll bar is drawn (though the rendered view of the document is cut off on the right).  

3 No vertical scroll bar is drawn, though the document does not all appear on the one screen. (Note: I believe that sometimes a vertical scroll bar may be drawn, but I am not able to make that happen this afternoon.)

4 Right-left scroll gestures with my mouse do not scroll right or left.

5 Up-down scroll gestures with my mouse wheel (or the equivalent) do scroll up and down.

6 If I click in the text area, page up and page down move through the document in something like the normal way. (I say 'something like' because without a scroll bar it doesn't feel quite normal.)

7 At the bottom of the document, some material at the end of the document is not visible.  That is, scroll-down gestures and the page-down key cease to have an effect, but the final part of the page is not visible.

8 Resizing the window in any direction (e.g. by making it taller, shorter, wider, narrower, or any combination of these) causes the text to reflow and to be displayed normally.  If I have the XML and HMLT versions of the document open in adjacent tabs, then after resizing the window, layout is essentially the same in the two tabs.

9 From the line breaking of paragraphs, it's possible to reconstruct (approximately) the width of the area for which the prose text has been formatted.  This varies with the size of the window at the time the XML document is loaded; very roughly, it's as if the renderer were overestimating the width of the display area by about 40% in each case.  

10 The amount of material not displayed at the bottom of the document also varies with the size of the window:  the smaller the window, the less material remains undisplayed; the larger (taller or wider) the window, the more material is undisplayed.

Comment 13

[C. M. Sperberg-McQueen]

The report in bug 448756 says that this happens only when the window is maximized; I observe it regardless of window size (as entailed by observation 9 in comment 12).

Clicking the green window-control button to maximize the window causes a reflow and successful formatting of the page; clicking the green button again to return to the original size gets me the display I originally expected.

Clicking the yellow window-control button to minimize the window, and then restoring the window by clicking on its representation in the dock, does not cause a reflow and leaves the problematic layout in place. 

This problem appears not to occur in Firefox 12 running under Windows (the only Windows Firefox readily available to me at the moment); there, the page is displayed as expected whether the window is maximized or not.

Comment 14

[C. M. Sperberg-McQueen]

Attachment: Simple test case for rendering width issue

In comment 4, Jonas Sicking asked for a compact test case.  In the event that a test case would still be useful, I attach a zip file containing a test XML document and an accompanying XSLT stylesheet.  They are also available on the Web at 

  http://blackmesatech.com/2013/07/testcase/ 

The XML document has a single element containing a lot of text.  The XSLT stylesheet simply wraps that text in an html document.  It seems to establish that the problem is not due solely to complexity in the XML or XSLT, or to interactions with user-supplied CSS.  Screen shots will follow.

Comment 15

[C. M. Sperberg-McQueen]

Attachment: testcase-screenshots.zip

The attachment is a zip file containing four PNG screen shots showing a Firefox 22 application window under Mac OS X 10.6.8.  Shot 1 shows a small window just after loading test.xml; shot 2 shows a window of approximately the same dimensions after resizing the window caused a redisplay.  Shots 3 and 4 show the same for a window made as wide a possible on the screen and big enough to display the entire text of the sample document.  Note that some text is invisible (e.g. the final comment in English) even though the window is big enough to display it.

These screen shots are available on the Web at 

  http://blackmesatech.com/2013/07/testcase/