Comments

• spocky Members

  February 2012 edited February 2012

  Still same behavior with Firefox 10.0.1 (and possibly IE8).
  Am I the only one affected ?
  
  To be more precise, this call :
  
  _sahi._getText(_sahi._byXPath("//html"))
  
  doesn't return the same text in chrome and firefox (only visible text in chrome, and all text in the page in firefox).
  I've also tested sahi pro with the same results.
• narayan Administrators

  February 2012

  Hi Spocky,
  
  Can you post a html snippet which we can use to reproduce this behaviour? Can you also specify what you are trying to do? Sahi has a different way of looking at things, and we may be able to suggest a different way.
  XPaths are something we stay away from, so cannot help on that.
  
  Regards,
  Narayan
• spocky Members

  February 2012

  Hi narayan,
  
  Thanks for your answer.
  
  I'm using behat to test my web app (it's like cucumber, but for php)
  It makes it easy to write some scripts to verify be behaviour of a web app.
  
  Ex :
  Given I am on "/some/page"
  When I fill "username" with "foo"
  And I fill "password" with "bar"
  And I press "login"
  Then I should see "welcome foo"
  
  In behat, the "I should see" part of the script internally uses "_sahi._getText(_sahi._byXPath("//html"))" to fetch the text available on the page so that behat can check wheter the text is available anywhere on the page.
  
  However, there is a big difference between Webkit and Firefox/IE that is quite easy to see.
  
  Go to a simple web site (let's say craigslist.com) and just execute _sahi._getText(_sahi._byXPath("//html")) is js console of both firefox and chrome.
  
  Let alone the fact that firefox returns the sahi debug cdata. Just compare the 2 string results.
  You'll see that in Chrome, only visible text is returned, whereas in firefox there is much more text (even invisible text is returned).
  
  We used to test with behat only in chrome. As we recently wanted to extend our tests to other browsers, we saw that many tests where misbehaving and found out it was because of this difference.
  
  Isn't there anything I can do to obtain the same behaviour everywhere ? What would you suggest ?
  
  Regards
• markct Members

  March 2012

  We are having this same problem as well. We are using Behat+Mink+Sahi.
  
  This issue has been reported to Behat/Mink's developer, and he says that this is a bug in Sahi. See github.com/Behat/Mink/issues/186
  
  The website we are testing uses text-transform:uppercase extensively. The way it currently stands, we would need to write two sets of tests - one for Firefox and one for WebKit browsers. This is unacceptable.
  
  Is there any plan to address this issue?
• spocky Members

  March 2012 edited April 2012

  At least we're not the only on affected by this behaviour.
  
  Waiting for a fix to this "issue", we managed to circumvent the case sensitive issue in 2 different ways (hopefully it'll prove useful to you).
  
  1- Using a regular expression with a recent behat version (>=january 2012)

  Then I should see text matching "(?i)YOUR TEXT"
  

  The (?i) part is used to set a "case insensitive" flag for the regular expression function.
  Please note that due to the fact that the tested string is interpreted as a regex, you have to be careful with special characters.
  
  2- Using a custom context function (add it to your browserContext.php)

  /**
  * Checks, that the specified text (whatever case) is visible on the page
  *
  * Then /^I should see case insensitive text "([^"]*)"$/
  */
  public function iShouldSeeCaseInsensitiveText($argument1)
  {
    $expected = strtolower(iconv("UTF-8", "ASCII//TRANSLIT", str_replace('\"', '"', $argument1)));
    $actual   = strtolower(iconv("UTF-8", "ASCII//TRANSLIT", $this->getSession()->getPage()->getText()));
  
    try {
      assertContains($expected, $actual);
    } catch (AssertException $e) {
      $message = sprintf('The text "%s" was not found anywhere in the text of the current page', $expected);
      throw new ResponseTextException($message, $this->getSession(), $e);
    }
  }
  

  Note that the use of iconv function was necessary so that diacritics are correctly evaluated (without it, uppercase accentuated letters were not transformed to lowercase).