Reset issue for overflow='hidden'
Foteos Macrides
guessing layout.
In:
http://www.macridesweb.com/oltest/MODAL.html
I use this javascript:
var
OLmRoot=(document.compatMode&&document.compatMode=='BackCompat')?'body':'html';
var root=document.getElementsByTagName(OLmRoot)[0];
if (root.style.overflow!='hidden') root.style.overflow='hidden';
to temporarily suppress any scrolling of the document by eliminating its
scroll bars (and later, after a user action, I restore the scroll bars).
To see the problem, scroll the document vertically until the 'Modal dialog'
link is at the top of the viewport, and then activate that link. In IE and
Opera there is a very modest horizontal shift of the document due to reflow
associated with the removal of the vertical scroll bar (because the
document content is using a horizontal centering style). But in Firefox the
document is reset (shifted both horizontally and vertically) to its 0,0
position before being centered horizontally.
I save the upper-left screen coordinates, and use self.scrollTo() to restore
the document's position when the scroll bars are restored, so this was not
a big issue in my mind, but a number of users have complained that, in so
many words, the substantial jump of the document display in Firefox is
jarring and causes them emotional distress. :<)
In any case, it does seem like a bug in Firefox when compared to IE and
Opera, so I'm raising the issue here for feedback from the Firefox
developers.
I'm using the recently released Firefox v2.0 (rv: 1.8.1), but was using
v1.5.0.8 (rv: 1.8.0.8) which also has this problem.
Fote
--
Martijn
I can see the problem in branch builds, but not with current trunk
build, so this seems to be fixed somehow in current trunk builds.
You can try it out yourself if you like:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Regards,
Martijn
> _______________________________________________
> dev-tech-layout mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-layout
>
Foteos Macrides
until v3.0? Is there any chance of getting it into a v2.0.x "automatic
upgrade" for general users of Firefox?
I tried doing the self.scrollTo() immediately after setting overflow to
'hidden' but that javascript function stops working until after the scroll
bars are restored. I guess, logically, the function shouldn't work, but
this still leaves me without a workaround for v2.0 or earlier.
Fote
--
"Martijn" <martijn...@gmail.com> wrote in message
news:mailman.1901.116472860...@lists.mozilla.org...
Martijn
> Does this mean that the fix will not become available in "formal releases"
> until v3.0? Is there any chance of getting it into a v2.0.x "automatic
> upgrade" for general users of Firefox?
Probably not, only crash bugs and security issues get fixed on branch
in general.
So unless the fix is somehow part of a crash/security fix, there is
little to no chance that it will get into the "automatic upgrade" for
Firfox2.0.x.
Regards,
Martijn
Eli Friedman
> Does this mean that the fix will not become available in "formal releases"
> until v3.0? Is there any chance of getting it into a v2.0.x "automatic
> upgrade" for general users of Firefox?
>
> I tried doing the self.scrollTo() immediately after setting overflow to
> 'hidden' but that javascript function stops working until after the scroll
> bars are restored. I guess, logically, the function shouldn't work, but
> this still leaves me without a workaround for v2.0 or earlier.
>
> Fote
Really? Seems to work fine in my testcases. There must have been a bug
when you tried it (or maybe a bug in my tests). Could you try it again?
(Logically, no, you shouldn't be able to do that, but you can anyway.)
-Eli
Foteos Macrides
I tried it again with Firefox 2.0, IE 7.0, and Opera 9.02, but
self.scrollTo() didn't work with any of them when overflow was set to
'hidden' for the documentElement.
Fote
--
"Eli Friedman" <sharp...@yahoo.com> wrote in message
news:VtadnYa0j8vhCfHY...@mozilla.org...
Eli Friedman
> Eli,
>
> I tried it again with Firefox 2.0, IE 7.0, and Opera 9.02, but
> self.scrollTo() didn't work with any of them when overflow was set to
> 'hidden' for the documentElement.
>
> Fote
Here's my code; are you trying to do something different?
-Eli
<!DOCTYPE html>
<button onclick="window.scrollTo(2000,2000);">Click</button>
<a href="#a">asdf</a>
1a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
2a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
3a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
4a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
5a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
6a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
7a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
8a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
9a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
10a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
11a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
12a<br>b<br>c<br>d<br>e<br>f<br>g<br>h<br>
<a name="a"><button onclick="var
h=document.getElementsByTagName('html')[0];h.style.overflow='hidden';
window.scrollTo(2000,2000);">Click</button></a>
Tony Mechelynck
This is a known bug: see https://bugzilla.mozilla.org/show_bug.cgi?id=351491
which is "fixed-1.8.1.1", meaning (IIUC) that the current Fx 2.0.0.1
pre-release nightlies have the fix, and that the next Fx 2.0 release will
probably have it too. Whether the fix will be propagated to Fx 1.5.0.9 (when
it comes out) is anyone's guess.
Note, by the way, that even without scrollbars it is always possible to scroll
the document by means of the keyboard.
Best regards,
Tony.
Foteos Macrides
The scrollTo() call works fine for all versions of all browsers (Firefox,
IE, Opera) on my WinXP with that javascript (whether inline as you had it,
or moved out to a function that is called on click), but not for any of them
when the documentElement's overflow is set to 'hidden' via the code in my
application.
What's even more strange is that if I put a test scrollTo() call for
scrolling to an arbitrary position IMMEDIATELY BEFORE the
document.getElementsByTagName('html')[0];h.style.overflow='hidden';
statement in my application, the scrolling works, but not if placed
IMMEDIATELY AFTER. And that's the case for all of the browsers, not anything
specific to Firefox. So something in addition to setting the overflow to
'hidden' must be causing my problem, but it doesn't look like I'll be
figuring out what that is tonight. When I do finally figure it out, if it's
anything relevant to Firefox development I'll post more in this thread.
Fote
--
"Eli Friedman" <sharp...@yahoo.com> wrote in message
news:4K-dnQ6yAJYzpvDY...@mozilla.org...
Foteos Macrides
Thanks for the pointer to that bugzilla bug entry, though when I read
through it I didn't grasp how it had to do with the bug I reported.
In any case, when I tried the "Minefield" v3.0a1 (rv: 1.9a1) nightly trunk
build which I got via the URL that Martijn posted, the actual bug discussed
at the start of this thread was fixed.
What is the URL for getting the current Fx 2.0.0.1 pre-release nightlies,
and when you say the fix will be in "the next Fx 2.0 release" does that mean
an update which users of Fx v2.0 (rv: 1.8.1) will be offered "automatically"
and in the not-too-distant future?
Fote
--
"Tony Mechelynck" <antoine.m...@belgacom.net> wrote in message
news:t5Wdne6sBNGQ6fDY...@mozilla.org...
Foteos Macrides
I tracked down and tried the "20061129 Bon Echo" v2.0.0.1pre (rv:
1.8.1.1pre) branch build, and the bug (inappropriate reset to the document's
0,0 on setting the documentElement overflow to 'hidden') is NOT fixed in
that.
Fote
--
"Foteos Macrides" <fot...@hotmail.com> wrote in message
news:lrKdnY6jcMcH0_PY...@mozilla.org...
Foteos Macrides
> [snip]
> What's even more strange is that if I put a test scrollTo() call for
> scrolling to an arbitrary position IMMEDIATELY BEFORE the
> document.getElementsByTagName('html')[0];h.style.overflow='hidden';
> statement in my application, the scrolling works, but not if placed
It does work if I impose a slight delay:
h=document.getElementsByTagName('html')[0];
h.style.overflow='hidden';
st=setTimeout("self.scrollTo(scLeft,scTop)",1);
Apparently a race condition can exist between the inappropriate reset of the
document to 0,0 upon setting the documentElement's overflow to 'hidden' and
the scrolling to a specified position for an immediately following
scrollTo() call.
Fote
--
Boris Zbarsky
> It does work if I impose a slight delay:
> st=setTimeout("self.scrollTo(scLeft,scTop)",1);
What's |self|?
It sounds like scrollTo is not flushing out pending layout/style changes. It
should be.
-Boris
Foteos Macrides
'self' is the current frame or iframe with an 'html' block. That code can
be changed to window.scrollTo(scLeft,scTop) with the same results -- an
apparent race condition for a bug associated with setting the
documentElement to 'hidden' -- which inappropriately resets the document to
0,0 and can do so after an immediately following scollTo() call unless
that's delayed so as to ensure that the scrollTo() in fact occurs after the
inappropriate reset.
I'm not sure what you mean by 'not flushing out pending layout/style
changes'. I do want the preceding h.style.overflow='hidden'; to be acted
up, and it is, with a reflow causing a slight shift to the right upon loss
of the vertical scroll bar for content that has a centered style.
If you haven't been following this thread, the 'inappropriate reset' bug is
gone in the 'Minefield' v3.0a1 (rv: 1.9a1) nightly trunk
build, but not in the v2.0 formal release nor the 'Bon Echo' v2.0.0.1pre
(rv: 1.8.1.1pre) branch build. I was trying to use the scrollTo() call as a
workaround for the bug until a v3.0 formal release eventually occurs.
Fote
--
Boris Zbarsky
> 'self' is the current frame or iframe with an 'html' block.
So 'self' is the window the code is running in? Thus when you do:
h=document.getElementsByTagName('html')[0];
h.style.overflow='hidden';
That's self.document you're working with?
> which inappropriately resets the document to
> 0,0 and can do so after an immediately following scollTo() call unless
> that's delayed so as to ensure that the scrollTo() in fact occurs after the
> inappropriate reset.
Interesting. Do you know where this "reset" is coming from? Is the behavior on
trunk as you describe?
> I'm not sure what you mean by 'not flushing out pending layout/style
> changes'.
Layout and style changes happen asynchronosly, normally. Calling some methods
will synchronously process them. window.scrollTo is one of those methods -- all
pending layout and style changes to the document inside the window are processed
before the scroll is attempted.
> If you haven't been following this thread, the 'inappropriate reset' bug is
> gone in the 'Minefield' v3.0a1 (rv: 1.9a1) nightly trunk
Oh, ok. That more or less means I don't care. ;) Though it _is_ pretty odd
that this happens on branch, given
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.761.2.64&mark=3940#3934>.
-Boris
Foteos Macrides
> Foteos Macrides wrote:
>> 'self' is the current frame or iframe with an 'html' block.
>
> So 'self' is the window the code is running in? Thus when you do:
>
> h=document.getElementsByTagName('html')[0];
> h.style.overflow='hidden';
>
> That's self.document you're working with?
I posted the actual code for my full application at the beginning of this
thread. This is 'simplified testing code' for Firefox based on what Eli
Friedman subsequently posted. The 'self' in the full application is a
variable affected by whether or not the application is dealing with frames
or an iframe, and the argument for the foo.document.getElementsByTagName()
call also is a variable, which could use 'body' instead of 'html' for old
versions of the supported browsers.
>> which inappropriately resets the document to 0,0 and can do so after an
>> immediately following scollTo() call unless that's delayed so as to
>> ensure that the scrollTo() in fact occurs after the inappropriate reset.
>
> Interesting. Do you know where this "reset" is coming from? Is the
> behavior on trunk as you describe?
Martijn tried my initial test case:
http://www.macridesweb.com/oltest/MODAL.html
with 'Minefield' and reported that the problem didn't occur with that, which
I've since confirmed. Tony Mechelynck posted that it's:
https://bugzilla.mozilla.org/show_bug.cgi?id=351491
and that it's "fixed-1.8.1.1" but that doesn't read to me like a description
of this bug, and the bug was still present in last night's 'Bon Echo'.
>> I'm not sure what you mean by 'not flushing out pending layout/style
>> changes'.
>
> Layout and style changes happen asynchronosly, normally. Calling some
> methods will synchronously process them. window.scrollTo is one of those
> methods -- all pending layout and style changes to the document inside the
> window are processed before the scroll is attempted.
Thanks for this explanation.
>> If you haven't been following this thread, the 'inappropriate reset' bug
>> is gone in the 'Minefield' v3.0a1 (rv: 1.9a1) nightly trunk
>
> Oh, ok. That more or less means I don't care. ;) Though it _is_ pretty
> odd that this happens on branch, given
> <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.761.2.64&mark=3940#3934>.
I'm not very good at searching for bugs on the bugzilla site, and haven't
found one which looks like this bug to me. If it went away 'fortuitously'
on trunk, I kinda worry about an uncaught regression occurring before the
eventual v3.0 formal release.
Fote
--
Boris Zbarsky
> I've since confirmed. Tony Mechelynck posted that it's:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=351491
That doesn't sound at all like the issue you describe, as you point out.
> I'm not very good at searching for bugs on the bugzilla site, and haven't
> found one which looks like this bug to me. If it went away 'fortuitously'
> on trunk, I kinda worry about an uncaught regression occurring before the
> eventual v3.0 formal release.
Agreed. We should check in a regression test for this, if any of our regression
test frameworks can deal with it...
-Boris
Foteos Macrides
> Note, by the way, that even without scrollbars it is always possible to
> scroll the document by means of the keyboard.
Thanks for pointing this out. The scrolling and paging keys are suppressed
in IE when the documentElement's overflow is set to 'hidden', but not in
Firefox or Opera. I added code in my application to suppress them in the
latter two browsers as well.
Fote
--
Foteos Macrides
> Foteos Macrides wrote:
>> I'm not very good at searching for bugs on the bugzilla site, and haven't
>> found one which looks like this bug to me. If it went away
>> 'fortuitously' on trunk, I kinda worry about an uncaught regression
>> occurring before the eventual v3.0 formal release.
>
> Agreed. We should check in a regression test for this, if any of our
> regression test frameworks can deal with it...
Boris,
Here's link:
http://www.macridesweb.com/oltest/hiddenProblem.html
for testing whether a regression occurs in Minefield for this problem.
Fote
--
Jeff Walden
> Here's link:
>
> http://www.macridesweb.com/oltest/hiddenProblem.html
>
> for testing whether a regression occurs in Minefield for this problem.
I filed bug 364184 to convert the testcase into a format suitable for one of our test suites.
Jeff
Foteos Macrides
I added comments elaborating on how to exercise the testcase for
https://bugzilla.mozilla.org/show_bug.cgi?id=364184
Fote
--