Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#14638 closed Bug (duplicate)

inconsistent startupFocus behavior in webkit when url a fragment identifier (# character)

Reported by: Kevin Kamel Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Cc:

Description

Steps to reproduce

  1. Open attached test file with a webkit browser.
  2. Press the test link, which replaces a textarea with CKEditor upon pressing a link which happens to reference "#".
  3. Observe page scroll, appears startupFocus is ignored

Expected result

startupFocus set to false should block the page from scrolling upon a replace() call.

Actual result

startupFocus is ignored when a fragment identifier is present within the url, allowing the page to scroll within webkit.

Other details (browser, OS, CKEditor version, installed plugins)

I observed this on the most recent versions of Safari and WebKit. It does not appear to occur on Firefox, but may affect IE.

I tried this on CKEditor 4.5.4, 4.5.8 and 4.5.9

Attachments (1)

startupFocus_bug.html (475 bytes) - added by Kevin Kamel 8 years ago.

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by Kevin Kamel

Attachment: startupFocus_bug.html added

comment:1 Changed 8 years ago by Kevin Kamel

Apologies. Step #1 should say:

  1. Open attached test file with a webkit browser, append a # sign to the url and press enter such that the loaded page contains an empty fragment identifier. For example:

http://www.example.com/startupFocus_bug.html#

This step is critical, as the bug will only occur when the current context contains such a fragment identifier.

Version 0, edited 8 years ago by Kevin Kamel (next)

comment:2 Changed 8 years ago by Jakub Ś

Resolution: duplicate
Status: newclosed
Version: 4.5.9

Hi @kamelkev

First of all I need to say this is a duplicate of #10749.

Second, I don't think startupFocus controls page scroll in a way it is described here.

Third, please see http://ckeditor.com/comment/127529#comment-127529 and tell me if you have any other reason for using # in URLs? If you want to have fake URL then javascript:void(0); sounds to me like a much better solution.

comment:3 Changed 8 years ago by Kevin Kamel

Hi @j.swiderski

The issue does appear to be a duplicate of #10749. Apologies. I searched for a long time, but I didn't see that particular one while digging.

I did however find quite a few posts on stackoverflow related to this issue, as well as others on your forum. Some of those posts implied that this issue was related to startupFocus, but upon a reread of that flag I can see it's related to something else. Apologies.

I read the CKEditor forum comment that you have referenced, and I also read the associated stackoverflow approach. I think the issue here is that you are advocating a solution that is not really in line with common or best practices these days. It is extremely common to encounter href="#", not just in jquery/jqueryui, but in many other libraries that are widely deployed.

The stackoverflow post you reference within your forum post really says it all: "I prefer to use <a id="the-link" href="#">Link</a> and then bind an event handler to the click listener somewhere in my javascript like..."

This is just the reality of ecosystem these days, and href="#" has only gotten more common. The forum thread you linked to is from 2013, and since then href="#" is even more common. So while I appreciate that there is an alternative, it doesn't really help me much because the code adding href="#" is not within my control.

comment:4 Changed 8 years ago by Jakub Ś

I think the issue here is that you are advocating a solution that is not really in line with common or best practices these days.

Thanks for explanation. I'm perfectly aware second solution is old and that '#' is more common. I just wanted to give you an alternative which has always worked without problems in CKEditor.

hat you are advocating a solution that is not really in line with common or best practices these days.

What I really don't like about first solution is that it is modifying the URL. IMHO it is very hard to call it a best prectice. While the concept is perfectly valid, I think the execution is poor and someone has forgotten to add evt.preventDefault() or provide hook/config option so that you could do it.

I'm not sure what that custom code is doing but I think that in general when link is not used for navigation, the last line, like in below samle code, is mandatory.

<a id="myCustLink" href="#">My Custom Link</a>
document.getElementById('myCustLink').addEventListener( 'click', function( evt ){
	//code here
	evt.preventDefault();		
});
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy