Tag Archives: Fix

Watir’s @browser.url returning the previous page’s url

Posted on by
3

I’ve come across a page which, when I navigate to it and ask it for it’s url (using @browser.url) gives me the previous page’s url. Very frustrating. To get around this, you can use direct DOM manipulation. Here’s a call you can use in place of @browser.url which will give you the actual url of the page:

my_current_url = @browser.js_eval("document.location.toString();")

The js_eval call takes a javascript command and returns any result. In this case, we ask the document (the root element of the document object model) and ask it for its location as a string. The javascript is evaluated, and the current url in the browser is returned. BTW, if you look at the firewatir code, the js_eval method is at the core of firewatir – it’s what passes commands to jssh and gets the results back.

Fix for Firewatir visible? method

Posted on by
Reply

The visible? method in the ruby Firewatir 1.6.2 gem isn’t great. After some hunting around, I ended up here and found a working monkeypatch. Here’s the code:


class Element
  def visible?
    assert_exists
    jssh_command = "var val = 'true'; var str = ''; var obj = #{element_object}; while (obj != null) { try { str = document.defaultView.getComputedStyle(obj,null).visibility; if (str=='hidden') { val = 'false'; break; } str = #{DOCUMENT_VAR}.defaultView.getComputedStyle(obj,null).display; if (str=='none') { val = 'false'; break; } } catch(err) {} obj = obj.parentNode; } val;"
    jssh_socket.send("#{jssh_command}\n", 0)
    vals = read_socket()
    return (vals == 'false') ? false : true
  end
  public:visible?
end

Works for me!

The page I got this from says that the above will be in the next version of Firewatir… I hope so, because it doesn’t work without it!

FireWatir JSSH “Unable to connect” – FIXED!

Posted on by
4

Firewatir is awesome. But… sometimes Firefox takes too long to load (eg: if you have loads of plugins) causing firewatir to timeout and give the following error:

Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Firefox is running with '-jssh' option

This was a major pain; painful enough to send me looking through the firewatir code in the hope that I’ll be able to fix it. Turns out the logic that deals with starting firefox and establishing a connection to JSSH needs only a minor change to fix the problem. The relevant code is in the firefox.rb file within the firewatir gem, specifically the set_defaults method. Here’s a monkeypatch to override the necessary method:


require "rubygems"
require "firewatir"

class FireWatir::Firefox
  # fixes the timeout caused by firefox taking ages to
  # load, preventing a connection from being made to JSSH
  def set_defaults(no_of_tries = 0)
    begin
      $jssh_socket = TCPSocket::new(MACHINE_IP, "9997")
      $jssh_socket.sync = true
      read_socket()
    rescue
      no_of_tries += 1
      sleep 0.1
      retry if no_of_tries < 300
      raise UnableToStartJSShException, "Unable to connect to machine : #{MACHINE_IP} on port 9997. Make sure that JSSh is properly installed and Firefox is running with '-jssh' option"
    end
    @error_checkers = []
  end
end

To use the patch, place it in a file that is read in before you use firewatir for the first time.

Firewatir tries to connect 3 times to JSSH after waiting for 2 seconds for Firefox to load. This is usually enough. But again, there are scenarios where 2 seconds and 3 connection attempts just isn’t enough. The very simple and slightly hacky fix that I tried worked beautifully… instead of trying 3 times, try 300 times instead with a simple sleep 0.1 just before the retry. This gives Firefox around 30 seconds to get its act together. As soon as it is ready, the test begins. It hasn’t caused any execution slowdown – in fact, now that I don’t have to run ‘failed’ tests at the end of a test run, I can just run everything once, saving loads of time! The joys of one-click-testing…
Since putting in this fix, I haven’t seen the problem again!

MS Access crashes when saving a query

Posted on by
Reply

I’ve been doing a fair bit of data reconciliation testing recently. One of the things I’m (reluctantly) using is Microsoft Access. There are many reasons to hate Access, here’s the latest one: sometimes, for no good reason, Access will have a total crash when you try to save a query. I bumped into this problem a few days ago. I couldn’t figure out what was wrong. I checked everything twice over – still nothing. Eventually I turned to Google, and after a few seconds found this: http://support.microsoft.com/?id=319491.

I opened it up, had a look at the “Symptoms” section where it says this: “When you try to save a modified query or run a query, Microsoft Access may quit unexpectedly without an error message.“. Yeah, that sounds about right. And it doesn’t sound like they feel particularly ashamed about it either.

The fix is to turn off the “auto tracking” function. The Auto Tracking function is really quite cool. If you change the name of a query, any other query that references it will be automatically updated with the new name. There aren’t too many nice things about Access, so it’s a real shame that it only works if you turn off those nice features off.

So. If you run into this problem, swap to a difference RDBMS. If you can’t, do the following:

  1. On the Tools menu, click Options.
  2. In the Options dialog box, click the General tab.
  3. Under Name AutoCorrect, click to clear the following check boxes:
    • Track name AutoCorrect into
    • Perform name AutoCorrect
    • Log name AutoCorrect changes
  4. Click OK.