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

[Kevin Kamel]

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

[Kevin Kamel]

Apologies. Step #1 should say:

1. Open attached test file with a webkit browser, append a # sign to the url and load the url 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.

[Jakub Ś]

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.

[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.

[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();		
});