 
[previous] |
No Timeouts For Opera
The latest Opera releases (v7.21 and 7.22) exhibit an unusual
behavior with regards to page scrolling and JavaScript timeouts in cross-frame
scenarios. Specifically, if you load a frameset, scroll one of the pages in the
frameset to a location other than its default (0,0) location, click through to
a second page, and then return to the original page via the back button of the
browser, you will find that all timeouts that are assigned to trigger within
the page you scrolled will be suspended--i.e., they will not execute after their
allotted timeout value. Various triggers seem to "release" this suspension, allowing
the timeouts to begin functioning again. For example, triggering any event within
the scrolled page that itself executes JavaScript (even something as simple as
return true) will lift the suspension and allow the timeouts to
execute normally. Scrolling the page also lifts the suspension, as does clicking
the mouse anywhere in the scrolled page.
Again, an example page may help demonstrate the problem more
clearly. Clicking on the following link opens a new window containing a frameset.
Each of the links in the left frame, when rolled over, will set a timeout
in the main frame. When that timeout expires, a simple alert box is displayed.
Go ahead and roll over the links initially to see how the alerts work in a normal
setting.
Opera and suspended timeouts
After you've seen the alert boxes in action, scroll the main page down
to the bottom (if your browser window is too large to allow scrolling in the
main page, then reduce it until you get scroll bars), then click
through to Page 2 from either the left frame or the main frame (leaving the main frame
in its scrolled down state). After loading Page 2,
use the back button of your browser to return to Page 1. Now, without clicking anywhere,
roll over the links in the left frame again. In Opera 7.21 and 7.22, no alert boxes appear.
Roll over the links a few times, and still no alert boxes. It is not until you do
something that "releases" the timeouts that you will see all the alert boxes that you've
stacked up as a result of rolling over the links. To accomplish this release, click the
mouse anywhere in the right frame.
While seemingly a minor problem, this behavior can have an annoying
effect on HM implementations. Timeout processing is critical in HM (especially with Opera
cross-frames settings; see our earlier discussion
for the reasons why), and when it's blocked, the menus simply won't work as they are
intended. In this specific case, for example, since the menus themselves are displayed
following timeout settings that are applied when the mouse rolls over navigation frame
links, these menus won't be displayed until the timeout suspension is somehow
lifted. Then, when it is lifted, the menus would all be immediately displayed
in quick succession as each of the timeouts set from the navigation page are executed in
sequence.
The answer, then, would seem to require us to do something on our own,
before the menus are popped up, to trigger the suspension release. We can't "click" the
document (we can issue a dispatchEvent, but this, in and of itself, does not
release the timeouts), and scrolling the page slightly on each menu popup is visually
unacceptable.
One further trigger that we were able to discover involved the loading
of a new image within the main page. Since this is something that can be done invisibly
to the end user (the new image can be safely defined as a small hidden object on the page),
this is the method we've chosen to work around the problem. We apply this image creation
and load process to each popup of a new menu, which effectively releases any timeout
suspensions that we may be experiencing within the content page and allows the menus to
appear as they would normally. Though invisible, we don't want to weigh down the content
page with an extra image it doesn't need; therefore, we apply this new processing only
to Opera 7.21 and later. If a future version of Opera should correct this problem, we'll
bracket the browser versions so as to not require an additional image in those browsers,
either.
Opera Freeze Frames
While we're on the topic of Opera cross-frame glitches, we thought
we should also alert you to a problem which effects all Opera 7.x versions. If you
reload a frameset (using the standard reload button on the toolbar), back up a page
using the standard back button, and then click through to a different page from
within that original page, the navigation page of the frameset will freeze. It
will remain this way until you reload the page again, or move to a page outside the
current frameset.
This problem appears to be completely unrelated to HM--or any other
script--processing. We were able to duplicate the bug using standard HTML pages with
no JavaScript whatsoever in this example:
Opera and frozen frames
We know of no workaround for this bug--which could affect any
Opera frameset regardless of JavaScript configurations--and have therefore added this behavior
to our Known Issues list. If you have any information
that may help us find a workaround for this issue, we'd love to hear about it.
Conclusion
We again offer our sincere thanks to all those who report problems,
and especially to those who offer reduced examples and specific instructions on replicating
the bugs. Such reports help us not only to make HM better, but also allow us,
when appropriate, to report the results of the problems to the browser developers
themselves, helping them to make a better product.
Files Changed in HM 5.3.1
- HM_ScriptDOM.js
- HM_ScriptOPR.js
- optimized/HM_ScriptDOM.js
- optimized/HM_ScriptOPR.js
[previous]
Created: November 20, 2003
Revised: November 20, 2003
URL: https://www.webreference.com/dhtml/hiermenus/inprogress/10/2.html
Find a programming school near you