Firefox XSL Zoom

[daamon]

Binary package hint: firefox

Produced on Ubuntu 9.10 using Firefox 3.5.7 (3.5.7+nobinonly-0ubuntu0.9.10.1).
Also produced on Ubuntu 9.10 using Firefox 3.7a1

Steps:
0. Reset Firefox zoom. (View -> Zoom -> Reset)
1. Go to page that uses XSL. Example, http://devedge-temp.mozilla.org/community/rss/index_en.xml
(page should render correctly)
2. Zoom in. (View > Zoom > Zoom In)
3. Reload the page (View > Reload)

The page is not viewed as before (correctly) and scroll bars are missing. This affects both, horizontal and vertical, scroll bars. Zooming out also causes display issues, such as elements of the page repeating.

Temporary Workaround:
1. Reset Firefox Zoom
2. Refresh page
3. Page should be displayed correctly again

[daamon (armomurha)]

Binary package hint: firefox

Produced on Ubuntu 9.10 using Firefox 3.5.7 (3.5.7+nobinonly-0ubuntu0.9.10.1).

Steps:
0. Reset Firefox zoom. (View -> Zoom -> Reset)
1. Go to page that uses XSL. Example, http://devedge-temp.mozilla.org/community/rss/index_en.xml
(page should render correctly)
2. Zoom in. (View > Zoom > Zoom In)
3. Reload the page (View > Reload)

The page is not viewed as before (correctly) and scroll bars are missing. This affects both, horizontal and vertical, scroll bars.

[Draycen DeCator (ddecator)]

This has also been confirmed on Ubuntu 9.10 using Firefox 3.5.7 and Firefox 3.7a1. The bug report can be found here: https://bugs.launchpad.net/firefox/+bug/515725 and is now linked to this bug.

[Draycen DeCator (ddecator)]

I have also been able to confirm this bug on my machine (Ubuntu 9.10) with Firefox 3.7a1. There also seems to be a bug on Mozilla's Bugzilla page, so I will link the two. I will also update the description with my findings. Thank you for taking the time to file this bug report and helping us to make Ubuntu better.

[C de-Avillez (hggdh2)]

Marking Triaged/Low, following work from ddecator.

[Ajschult (ajschult)]

Created attachment 439822
xslt for testcase

With a 20100418 mozilla-central linux build, any xhtml+xslt document only uses part of the window when zoomed out (full page zoom) -- it uses the upper-left hand part corresponding to the scaled-down browser window. The leftover parts of the window on the right and bottom render gray or pull in random video memory.

This regressed in 2008 due to bug 406784.

I also saw this effect with a windows build.

[Ajschult (ajschult)]

Created attachment 439823
testcase

1. Load the testcase
2. Zoom out (ctrl+-)
3. Reload

(right and bottom of the browser window will render poorly)

This doesn't seem to show the bug when trying to pull test.xsl from bugzilla, so you might have to download both and point the xhtml to the local xsl.

[L. David Baron (dbaron)]

Created attachment 439826
testcase

maybe it'll work if I change & to & ?

[L. David Baron (dbaron)]

Created attachment 439831
testcase

... and not cross-site either

[L. David Baron (dbaron)]

I stumbled upon this bug while going through Core bugs (in particular, those with "CSS") that are languishing in Firefox::General.

Marking as duplicate of a later bug that has a testcase...

*** This bug has been marked as a duplicate of bug 560145 ***

[L. David Baron (dbaron)]

This is the sort of bug you get when somebody makes a choice between device pixels and CSS pixels incorrectly.

(I think I commented on a very similar bug somewhere else; this might be a duplicate.)

[L. David Baron (dbaron)]

*** Bug 509398 has been marked as a duplicate of this bug. ***

[L. David Baron (dbaron)]

(In reply to comment #4)
> This is the sort of bug you get when somebody makes a choice between device
> pixels and CSS pixels incorrectly.
>
> (I think I commented on a very similar bug somewhere else; this might be a
> duplicate.)

By that: I mean there's a piece of code somewhere making the wrong choice between calling a function like AppUnitsToCSSPixels and AppUnitsToDevPixels, and the bug will be fixed by finding and fixing that code. (The trick is finding the right one so as not to break anything else. :-)

[Micah Gersten (micahg)]

New upstream bug.

[Alexandro Fernandez (alexandro-fernandez)]

I Tried:

2. Zoom out (in a new tab)
1. Load the testcase
(3. Reload not needed)

-> ? Is this maybe a DocumentViewer Initialisation Problem? *
-> ? Where is the transformation result passed to the Viewer? *

* Perhaps the conversion inconsistency can be found via search on http://mxr.mozilla.org/mozilla1.9.2/source/

[Alexandro Fernandez (alexandro-fernandez)]

FF 4b shows up same issue.

[Alexandro Fernandez (alexandro-fernandez)]

Please Help.
Sombody with knowledge. This is a really nasty bug in such good software full of pieces.
I'm no programmer. But if two eyes and a nose.

4. Resize the window and Tum Ta Da avery(important)thing is fine again.

So I guess it must (!) be an Init Problem.

For the ones in deeper Mozilla Code Space
-> ? Could you have a look at:
[nsPresContext.cpp]
line 842| nsPresContext::Init()

http://mxr.mozilla.org/mozilla1.9.2/source/layout/base/nsPresContext.cpp#842

[Alexandro Fernandez (alexandro-fernandez)]

Units I'm loving them :-)
nscoord
AppUnits
DevPixel
CSSPixel
(...)

5. try text zoom only -> no bug

Search for mFullZoom resp. aZoom resulted in not so many matches.

[Alexandro Fernandez (alexandro-fernandez)]

6. try private browsing mode -> no bug (as fullzoom is reseted to 1 on every refresh)

[Alexandro Fernandez (alexandro-fernandez)]

Question is this map right?

  PresShell --holds reference to--> output Doc (presentation in memory)
        |
  is assigned to
        |
       V
 PresContext------------------
        | ________________
        | | mVisibleArea ------is bound to-------> gBrowser (XUL chrome browser)
        | |
        | |
        | |________________
        | ________________

[Alexandro Fernandez (alexandro-fernandez)]

Googling helps, the answer to my question is here:

http://www.mozilla.org/newlayout/doc/

[Alexandro Fernandez (alexandro-fernandez)]

Suggestion/Workaround (as zooming is not so important on transformed docs):

- Reset zoomlevel to 1 while Parser is transforming Doc.
- After Doc-load complete restore zoomlevel to the original one.

I'm leaving this here, with a final open question to professionals:
How could this be done?

[L. David Baron (dbaron)]

(In reply to comment #10)
> 5. try text zoom only -> no bug
>
> Search for mFullZoom resp. aZoom resulted in not so many matches.

The difference here is that full zoom changes the ratio of CSS pixels to device pixels, while text zoom does not. See comment 6.

[Alexandro Fernandez (alexandro-fernandez)]

Actually this issue doesn't get out of my mind.

I added the addon "DOM Inspector" to my browser.
This is the structure I get for my local copy of the testcase:

#document
  #transformiix:result
    #text

If I save the testcase file (via file->save page) the resulting file contains this DOM structure.
I cannot see a reason, why the root element of the transformed doc is always <result>.
On initializing PresShell a root frame is created from this element, I think.
Eventually, as Firefox is css driven, this breaks the presentation of the doc. I guess <result> is shrinked down to the minimum size (viewport x zoomfactor) then, because there are no style rules for it.

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Launchpad

Actually this issue doesn't get out of my mind.

I added the addon "DOM Inspector" to my browser.
This is the structure I get for my local copy of the testcase:

#document
  #transformiix:result
    #text

If I save the testcase file (via file->save page) the resulting file contains this DOM structure.
I cannot see a reason, why the root element of the transformed doc is always <result>.
On initializing PresShell a root frame is created from this element, I think.
Eventually, as Firefox is css driven, this breaks the presentation of the doc. I guess <result> is shrinked down to the minimum size (viewport x zoomfactor) then, because there are no style rules for it.

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Please delete Comment

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

My Comment 15 was really stupid.(apologize for spaming here)
I didn't grasp, what David Baron said in Comment 6.

For someone like me:
 http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
 [About pixels and device pixels (written for webdesigners)]

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Created attachment 492646
xsl stylesheet for xhtml.testcase

This is the stylesheet for the xhtml.testcase

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Created attachment 492650
xhtml.testcase

This is a xhtml.testcase showing the bug (plus screenshot of it).

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Created attachment 492692
xhtml.testcase -> xsl stylesheet

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Created attachment 492696
xhtml.testcase -> xml document

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Jonas Sicking said:
"We need a better way of setting up the XSLT result document" [...]
"For example if
we tore down the DocumentViewer and set up a new one we might be able to use
existing functions rather then the current DocumentViewerImpl::SetDOMDocument
hack." (Bug:281022 Date:2005-02-03)

As I understand now, the fast development of Firefox makes it troublesome to update old unknown code to the new firefox design.

So I hope the developers will manage it (I was a little impatient)

Regards

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

@ David Baron:

Could you have a quick look at
line |738ns DocumentViewer.cpp [InitPresentationStuff()] please.
http://mxr.mozilla.org/mozilla1.9.2/source/layout/base/nsDocumentViewer.cpp#738

(If I'm totally in the wrong place, skip this comment)

How are mbounds computed in the init process of the view manager?

[Alexandro-fernandez-gmx (alexandro-fernandez-gmx)]

Additional notes:
If one of the testcases is loaded into an iframe of a zoomed doc -> no bug
So this might be a workaround for now.

Regards