Open
Bug 248023
Opened 20 years ago
Updated 2 years ago
many javascript popups cause document scrolling
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: jwz, Unassigned)
References
()
Details
(Keywords: testcase, Whiteboard: DUPEME)
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: http://www.klockwerks.com/html/frames/jclocks.html 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•20 years ago
|
||
CONFIRMING. Both that Mozilla Firefox (build 20040621 branch) will scroll back up, and that IE 6 does not.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•20 years ago
|
||
This is the code for the bottom right image at the provided URL: <p><a href="#"; onMouseDown="MM_openBrWindow('../../graphics/jpegs/clock_gallery/fullsize/562brasspot.jpg', '','width=246,height=452')"><img 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 window.open(theURL,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. http://devedge.netscape.com/library/manuals/2000/javascript/1.3/guide/evnt.html#1010423 That means the resource pointed by <a href="#" ...> must be retrieved. After searching carefully http://www.ietf.org/rfc/rfc2396.txt (section G.4. Modifications from RFC 1808 and section 4.2. Same-document References) and http://www.ietf.org/rfc/rfc1808.txt (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•20 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: http://www10.brinkster.com/doctorunclear/Bugzilla/Bug248023.html 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
Comment 4•20 years ago
|
||
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 6•17 years ago
|
||
I get the actual results with Seamonkey 1.5a rv:1.9a3pre Gecko/2007020709 under XP Pro SP2. I load http://www.gtalbot.org/BugzillaSection/Bug248023.html 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 http://www.klockwerks.com/html/frames/jclocks.html has been changed and no longer relies on javascript window.open() but on target attribute: e.g.: <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•17 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: return 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" e.g.: http://msdn.microsoft.com/workshop/author/dhtml/reference/tips/tips.asp#Canceling_a_Button_C "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
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 8•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•