The default bug view has changed. See this FAQ.

many javascript popups cause document scrolling




DOM: Core & HTML
13 years ago
8 years ago


(Reporter: Jamie Zawinski, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: DUPEME, URL)



13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

I encounter many sites that have galleries where you click on a thumbnail to get
a popup window with the larger image.  On almost all of these sites, this causes
the thumbnail page to scroll back to the top.

Now, I realize that it's possible for these sites to be coded such that they do
not cause scrolling.  However, they are not so coded.  This leads me to assume
that, on MSIE, scrolling does not occur.

Therefore, it would be good for Mozilla to emulate this behavior, right?

Here's an example:

In Mozilla 1.6, every time you click on a link, the popup appears and the
thumbnail page scrolls back to the top.

FWIW, no auto-scrolling occurs in Safari.

Reproducible: Always
Steps to Reproduce:

Comment 1

13 years ago
CONFIRMING.  Both that Mozilla Firefox (build 20040621 branch) will scroll back
up, and that IE 6 does not.
Ever confirmed: true

Comment 2

13 years ago
This is the code for the bottom right image at the provided URL:

<p><a href="#";
src="../../graphics/jpegs/clock_gallery/thumb/t562brasspot.jpg" width="64"
height="112" border="0"></a></p>

and this is the function:

function MM_openBrWindow(theURL,winName,features) { //v2.0,winName,features);

Note *and this is very important* that there is no return false in the event
attribute handler or in the function. Therefore the default action of the
element, here an anchor, *must* be followed through.

That means the resource pointed by <a href="#" ...> must be retrieved. 

After searching carefully 
(section G.4. Modifications from RFC 1808 and section 4.2. Same-document
References) and
(section 2.4.1. Parsing the Fragment Identifier)
I can not find a clear, explicit definition of how browsers should handle <a
href="#" ...>. The closest I could find was:
   an empty URI reference within a
   document is interpreted as a reference to the start of that document,
   and a reference containing only a fragment identifier is a reference
   to the identified fragment of that document.
Section 4.2. Same-document References of rfc2396.txt

I even asked help in alt.html on this. Some say href="#" should be invalid
according to specs and should fall under error correction; others say href="#"
brings document to top as a de facto standard among browser.

RFC1808, in section 2.2 defines in modified BNF form
 "fragment = 1*pchar"
and mentions that the 1* means "[one] or more repetitions of the [pchar].

So, zero repetitions is not allowed and href="#" is therefore an error.

Since it is an error then the browser, as per the spec, is at liberty to
interperet it as the browser sees fit. There is no "correct" behaviour.
Credits to Richard F. on this.

Finally, I tried several times clicking images at the provided URL and MSIE 6
brings the document to the top sometimes but not consistently.
I'd be surprised if this bug is a valid bug.
Keywords: qawanted
Whiteboard: [INVALID?]

Comment 3

13 years ago
Ok, there seems to be a valid bug here after all. I created a demo page for
testing all this. On an onclick event, Mozilla responds as expected AFAICS. On
an onmousedown though, things are not as expected even when the default action
is canceled. In other words, load this demo page:

and follow instructions, explanations, etc. Link #2 should open the popup and
NOT bring the opener document at its top but it does in Mozilla 1.8a2 build
2004063008 and in Firefox 0.9.1 build 20040626 rv 1.7 under XP Pro SP1a.

OS -> All
Keywords: qawanted → testcase
OS: Linux → All
Whiteboard: [INVALID?]
The difference is that in IE cancelling the mousedown cancels the click as well;
in Mozilla it does not.  That's been filed for years now.
Whiteboard: DUPEME

Comment 5

12 years ago
WFM 1.7.5, Linux.

Comment 6

10 years ago
I get the actual results with Seamonkey 1.5a rv:1.9a3pre Gecko/2007020709 under XP Pro SP2. I load

then I click Link #2 (which has return false) and the opener/main window/parent window gets back at the top of the opener/main window/parent document.

This happens regardless of property value (with mousedown or without mousedown) of the dom.popup_allowed_events preference name.

So the bug is still happening and reproducible.

OTOH, the code at the klockwerks: clocksamples webpage

has been changed and no longer relies on javascript but on target attribute:


<a href="images/2029Wheels.jpg" target="_blank"><img src="images/2029tWheels.jpg" width="85" height="115" border="0"></a>
See the right-most and bottom-most antique item on that page:
Title: Clock on Iron Wheels
Height: 20 "
Serial Number: 2029

I am therefore updating the URL provided in this bug report.

Comment 7

10 years ago
> The difference is that in IE cancelling the mousedown cancels the click as
> well;
> in Mozilla it does not.

The way I understand a "return false" instruction is that the default action of the element, - here, a linked resource which should load+replace in the opener window - is canceled, is not carried on. Now, if "return false" should also cancel the implicit/inherent click event as well (or even also stop propagation within DOM tree) is another story or extra, additional matters which does not (or should not) make a difference in this bug.

In Javascript 1.3 Core Reference, all I found basically was this:

Specifies the value to be returned by a function.

At MSDN, there are examples given where return false is said to "canceling the default action"

"The other a elements correctly bind the return value to the event, hence the default action can be canceled when false is returned."

>  That's been filed for years now.

FWIW, I've searched considerably which bug may be addressing or about the cancelling the mousedown cancels the click as well and couldn't find any. The closest I found was bug 366544
Assignee: general → nobody
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.