"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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
