Reset issue for overflow='hidden'

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Reset issue for overflow='hidden'

Foteos  Macrides
I'm not sure if this is a layout or DOM issue (or something else), but I'm
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
--


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Martijn-4
Yeah, I see what you mean.
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

On 11/28/06, Foteos  Macrides <[hidden email]> wrote:

> I'm not sure if this is a layout or DOM issue (or something else), but I'm
> 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
> --
>
>
> _______________________________________________
> dev-tech-layout mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-layout
>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
In reply to this post by Foteos Macrides
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
--

"Martijn" <[hidden email]> wrote in message
news:[hidden email]...

> Yeah, I see what you mean.
> 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
>
> On 11/28/06, Foteos  Macrides <[hidden email]> wrote:
>> I'm not sure if this is a layout or DOM issue (or something else), but
>> I'm
>> 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
>> --
>>
>>
>> _______________________________________________
>> dev-tech-layout mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-layout
>>


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Martijn-4
On 11/28/06, Foteos  Macrides <[hidden email]> wrote:
> 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

> 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" <[hidden email]> wrote in message
> news:[hidden email]...
> > Yeah, I see what you mean.
> > 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
> >
> > On 11/28/06, Foteos  Macrides <[hidden email]> wrote:
> >> I'm not sure if this is a layout or DOM issue (or something else), but
> >> I'm
> >> 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
> >> --
> >>
> >>
> >> _______________________________________________
> >> dev-tech-layout mailing list
> >> [hidden email]
> >> https://lists.mozilla.org/listinfo/dev-tech-layout
> >>
>
>
> _______________________________________________
> dev-tech-layout mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-layout
>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Eli Friedman
In reply to this post by Foteos Macrides
Foteos Macrides wrote:

> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
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
--

"Eli Friedman" <[hidden email]> wrote in message
news:[hidden email]...

> Foteos Macrides wrote:
>> 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


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Eli Friedman
Foteos Macrides wrote:
> 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>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Tony Mechelynck
In reply to this post by Foteos Macrides
Foteos Macrides wrote:

> I'm not sure if this is a layout or DOM issue (or something else), but I'm
> 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

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.
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
In reply to this post by Eli Friedman
Eli,

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" <[hidden email]> wrote in message
news:[hidden email]...

> Foteos Macrides wrote:
>> 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>


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
In reply to this post by Tony Mechelynck
Tony,

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" <[hidden email]> wrote in message
news:[hidden email]...

> Foteos Macrides wrote:
>> I'm not sure if this is a layout or DOM issue (or something else), but
>> I'm 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
>
> 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.


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
Tony,

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" <[hidden email]> wrote in message
news:[hidden email]...

> Tony,
>
> 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" <[hidden email]> wrote in message
> news:[hidden email]...
>> Foteos Macrides wrote:
>>> I'm not sure if this is a layout or DOM issue (or something else), but
>>> I'm 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
>>
>> 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.
>
>


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
In reply to this post by Foteos Macrides
"Foteos Macrides" wrote:
> [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
> IMMEDIATELY AFTER. [snip]

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
--


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Boris Zbarsky
Foteos Macrides wrote:
> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
"Boris Zbarsky" wrote
> Foteos Macrides wrote:
>> 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.

'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
--


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Boris Zbarsky
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?

> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
"Boris Zbarsky" wrote:
> 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
--


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Boris Zbarsky
Foteos Macrides wrote:
> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
In reply to this post by Tony Mechelynck
"Tony Mechelynck" wrote:
> 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
--


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Foteos  Macrides
In reply to this post by Boris Zbarsky
"Boris Zbarsky" <[hidden email]> wrote:
> 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
--


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reset issue for overflow='hidden'

Jeff Walden-2
Foteos Macrides wrote:
> 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
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
12