Skip to content
This repository has been archived by the owner on May 30, 2023. It is now read-only.

element.webkitMatchesSelector in phantomjs does not report ":focus" accurately #10427

Closed
ryangreenberg opened this issue Mar 14, 2012 · 64 comments

Comments

@ryangreenberg
Copy link

[email protected] commented:

Which version of PhantomJS are you using? 1.4.1

What steps will reproduce the problem?

  1. Run the provided test script with the test HTML (below).

What is the expected output? What do you see instead?
I expect :focus to be true after triggering a focus event on an element. Instead it is false.

Which operating system are you using? OS X 10.7.3

Did you use binary PhantomJS or did you compile it from source? Compiled.

Here is the output of my test script in Chrome, Safari, and PhantomJS:

Chrome

navigator.userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.54 Safari/535.19
$('#some-input').is(':focus'): true
$input[0].webkitMatchesSelector(':focus'): true
$input[0] == document.activeElement: true

Safari

navigator.userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.54.16 (KHTML, like Gecko) Version/5.1.4 Safari/534.54.16
$('#some-input').is(':focus'): true
$input[0].webkitMatchesSelector(':focus'): true
$input[0] == document.activeElement: true

PhantomJS 1.4.1

navigator.userAgent: Mozilla/5.0 (Macintosh; PPC Mac OS X) AppleWebKit/534.34 (KHTML, like Gecko) PhantomJS/1.4.1 Safari/534.34
$('#some-input').is(':focus'): false
$input[0].webkitMatchesSelector(':focus'): false
$input[0] == document.activeElement: true

Test HTML
<!DOCTYPE html>
<html>
<head>
<title>:focus check</title>
<script src="http://code.jquery.com/jquery.js&quot;&gt;&lt;/script>
<script>
$(function(){
console.log("navigator.userAgent: " + navigator.userAgent);

// Simple case
$input = $('#some-input');
$input.focus();
console.log(&quot;$('#some-input').is(':focus'): &quot; + $('#some-input').is(':focus'));

// Similar case
$input.focus();
console.log(&quot;$input[0].webkitMatchesSelector(':focus'): &quot; + $input[0].webkitMatchesSelector(':focus'));

// When a native matchesSelector isn't available, jQuery uses:
// 
//  focus: function( elem ) {
//     return elem === elem.ownerDocument.activeElement;
//  }
// 
// The input == document.activeElement, which suggests that the bug is in webkitMatchesSelector
console.log(&quot;$input[0] == document.activeElement: &quot; + ($input[0] == document.activeElement));

});
</script>
</head>
<body>
<form>
<input id="some-input">
</form>
</body>
</html>

Test script:
var page = require('webpage').create();
page.onConsoleMessage = function(msg) { console.log(msg); };

page.open('file:///' + phantom.libraryPath + '/focus_test.html', function (status) {
if (status !== 'success') {
console.log('Could not open URL');
}
phantom.exit();
});

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #427.
🌟   16 people had starred this issue at the time of migration.

@spmason
Copy link

spmason commented Apr 3, 2012

[email protected] commented:

I can confirm this is an issue in 1.4.1, also in 1.5.0 as well

I'm working around by using "elem === elem.ownerDocument.activeElement" instead, but it's not pretty.

Seems to work fine in Chrome 17 and Safari 5.1.5 - I'm not sure if these are using more recent versions of webkit though

@robotarmy
Copy link

[email protected] commented:

Please fix :D

@philfreo
Copy link

philfreo commented Mar 9, 2013

[email protected] commented:

Please fix!

@philfreo
Copy link

philfreo commented Mar 9, 2013

[email protected] commented:

// Patch $el.is(':focus') until PhantomJS supports it properly.
// https://code.google.com/p/phantomjs/issues/detail?id=427
var _jQuery_is = jQuery.fn.is;
jQuery.fn.is = function(s) {
if (s === ':focus') {
return this.get(0) === document.activeElement;
}
return _jQuery_is.apply(this, arguments);
};

This workaround may help some (put this in your test runner code)

@realyze
Copy link

realyze commented May 3, 2013

+1

4 similar comments
@caiges
Copy link

caiges commented May 10, 2013

+1

@tjvantoll
Copy link

+1

@TheCloudlessSky
Copy link

+1

@camsong
Copy link

camsong commented May 13, 2013

👍

@JamesMGreene
Copy link
Collaborator

Since this bug specifically mentions jQuery, I'll note that jQuery added a workaround for this WebKit bug in jQuery core 1.8.2: http://bugs.jquery.com/ticket/12492

@Mr0grog
Copy link

Mr0grog commented Jul 10, 2013

Though this has been fixed in jQuery, I'm using Poltergeist (a PhantomJS driver for Capybara, which is a browser testing driver for Ruby) for a lot of integration testing. I'd like to be able to test whether an element has focus and it seems like the natural way to do that would be to use the :focus selector. It would be great if this was fixed.

I'd also guess the cause of this is the same as #11432.

@ccidral
Copy link

ccidral commented Aug 21, 2013

+1

3 similar comments
@Flamefork
Copy link

+1

@ralfthewise
Copy link

+1

@roelrz
Copy link

roelrz commented Oct 2, 2013

+1

@vellotis
Copy link

vellotis commented Oct 8, 2013

+1
If I want to get currently focused element, I have to mock implementation framework which is not a part of BDD principles. The same downside exists in HTMLUnit also.

@vincentdieltiens
Copy link

+1

1 similar comment
@SebiTimeWaster
Copy link

+1

@lijunle
Copy link

lijunle commented Jan 3, 2014

Please fix it!

@coledot
Copy link

coledot commented Jan 13, 2014

+1

@silvinobarreiros
Copy link

+1

1 similar comment
@joanna1010
Copy link

+1

@rgl
Copy link

rgl commented Apr 14, 2014

Any progress on fixing this bug?

@barnomics
Copy link

+1

Would be nice to test accessibly features but no can do without a :focus element or document.activeElement

@lorenooliveira
Copy link

+1

1 similar comment
@grossadamm
Copy link

+1

@vickiccole
Copy link

+1

3 similar comments
@albinekb
Copy link

+1

@tiffanywei
Copy link

+1

@emilioplatzer
Copy link

+1

@garex
Copy link

garex commented Apr 25, 2016

Another possible patch (rude)

// it's for casperjs, but I think you will catch the idea
this.evaluate(function() { document.hasFocus = function() { return true } })

@workmanw
Copy link

+1

@sgress454
Copy link

@garex I tried something like that at one point without much luck -- I don't think the :focus selector just relies on document.hasFocus() returning true, but rather that whatever underlying conditions cause hasFocus() to return true must be met in order for the :focus selector to work.

@Jevin23
Copy link

Jevin23 commented May 7, 2016

+1

@kryptan
Copy link

kryptan commented Jan 3, 2017

I experimented with this a bit using a 2.1 branch (master crashes for me).

First I tried to fix it in PhantomJS itself, but calling QWebFrame::setFocus() on m_currentFrame or any other frame in webpage.cpp does not have any effect.

Next I looked into WebKit sources, the :focus pseudo class is checked here. SelectorChecker::matchesFocusPseudoClass function calls SelectorChecker::isFrameFocused which in turn calls FrameSelection::isFocusedAndActive. Changing FrameSelection::isFocusedAndActive to always return true fixes this issue although it feels like a hack, I don't know what a proper solution here would be.

P.S. I suggest owner of this repo to remove all junk +1 comments and block their authors.

@vitallium
Copy link
Collaborator

vitallium commented Jan 11, 2017

Can someone check it with recently released 2.5 beta version? Thanks!

@cleforwen
Copy link

+1

@jameswomack
Copy link

@vitallium Where can I download a version of 2.5 that will work with Selenium/Nightwatch.js? What I downloaded from https://bitbucket.org/ariya/phantomjs/downloads/ wasn't recognized by Selenium.

@DustinAshley
Copy link

+1

@Vishwaas
Copy link

+1

markdicksonjr added a commit to markdicksonjr/ember-paper that referenced this issue Sep 29, 2017
@srescio
Copy link

srescio commented Oct 29, 2017

+1

@ghost ghost removed 1.x labels Jan 10, 2018
pauln pushed a commit to pauln/ember-paper that referenced this issue May 28, 2018
@stale stale bot added the stale label Dec 25, 2019
@stale
Copy link

stale bot commented Dec 28, 2019

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!

@stale stale bot closed this as completed Dec 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests