Closed Bug 553616 Opened 14 years ago Closed 14 years ago

Context menu: Paste string into location bar

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Product:
Mozilla QA Graveyard
Component:
Mozmill Tests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tracy, Assigned: abillings)

References

Details

Attachments

(7 files, 6 obsolete files)

Rev 4 of patch
2.48 KB, patch
whimboo
: review+
Details | Diff | Splinter Review
Failure on 1.9.1
6.98 KB, text/plain
Details
Patch to use utils clear clipboard function for default branch
1.09 KB, patch
gmealer
: review+
Details | Diff | Splinter Review
Fix spacing and final semi missed in code review
1.12 KB, patch
u279076
: review+
Details | Diff | Splinter Review
Patch to use utils clear clipboard function for 1.9.2 branch
1.14 KB, patch
gmealer
: review+
Details | Diff | Splinter Review
Port of testPasteLocationBar.js to mozilla 1.9.1
4.47 KB, patch
gmealer
: review+
Details | Diff | Splinter Review
Added ">" to the end of Al's email address
1.38 KB, patch
u279076
: review+
Details | Diff | Splinter Review 
write mozmill test case for Litmus "Context menu: Paste"
test case 8443

This will only partially cover the litmus test case. Only steps 1-2 are doable with Mozmill.  Besides, the other steps are really tests of general clipboard functionality not related to awesomebar.
Assignee: twalker → nobody
Assignee: nobody → abillings
First attempt at this testcase for review.
Attachment #452069 - Flags: review?
Attachment #452069 - Flags: review? → review?(hskupin)
Crap, the "copy" doesn't seem to be working on Firefox 3.5. I need to figure out why.
Status: NEW → ASSIGNED
Comment on attachment 452069 [details] [diff] [review]
testPasteLocationBar.js and copypaste.html used by it

>+++ b/firefox/test-files/awesomebar/copypaste.html
>@@ -0,0 +1,5 @@
>+<html>
>+<body">
>+ <p>Lorem <span id="ipsum">ipsum</span> dolor sit amet, consectetur adipiscing elit.</p>
>+</body>
>+</html>
>\ No newline at end of file

Can you simply add a new line at the end? Thanks.

>+++ b/firefox/testAwesomeBar/testPasteLocationBar.js
>+/* ***** BEGIN LICENSE BLOCK *****
>+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1

Please use the new Public Domain license type. See one of the template files.

>+// Include necessary modules
>+var RELATIVE_ROOT = '../../shared-modules';
>+var MODULE_REQUIRES = ['ToolbarAPI', 'UtilsAPI', 'PlacesAPI'];
>+
>+const gDelay = 200;
>+const gTimeout = 5000;

Please also update the declarations to match the style we use in the templates, i.e. modaldialog.js

>+const testSite = {url : 'http://hg.mozilla.org/qa/mozmill-tests/raw-file/tip/firefox/test-files/awesomebar/copypaste.html'};

Looks like this is a leftover. Please remove it.

>+var setupModule = function(module)
>+{
>+  module.controller = mozmill.getBrowserController();
>+  module.locationBar =  new ToolbarAPI.locationBar(controller);

Remove all module instances and the parameter too. Place the opening { bracket in the same line as the function name.

>+   // Clear complete history so we don't get interference from previous entries
>+  try {
>+    PlacesAPI.historyService.removeAllPages();
>+  } catch (ex) {}

That interfers with bug 572403. We hope to get this in today, so please update your call to use the new method of the PlacesAPI.

>+  // Open the test page
>+  locationBar.loadURL(localTestFolder + "awesomebar/copypaste.html");
>+  controller.waitForPageLoad();

Please use controller.open() here. loadURL is only needed when you want to run tests against the location bar.

>+  // Focus on page, select text and copy to clipboard
>+  controller.doubleClick(new elementslib.ID(controller.window.document, 'ipsum'));

Please instantiate the element in it's own line so we have it as a variable available.

>+  // Clear the locationBar and rightclick in it for context menu
>+  locationBar.clear();
>+  controller.rightclick(locationBar.urlbar, 150, 0);

Instead of using a hard-coded value we should retrieve the boundaries of the elements box and compute the center position. 

>+  // Hack to paste from contextmenu in urlbar since it has no id
>+  controller.click(new elementslib.Lookup(controller.window.document, '/id("main-window")/id("navigator-toolbox")/id("nav-bar")/id("urlbar-container")/id("urlbar")/anon({"class":"autocomplete-textbox-container"})/anon({"anonid":"textbox-input-box"})/anon({"anonid":"input-box-contextmenu"})/{"label":"Paste","accesskey":"p","cmd":"cmd_paste"}'));

Please file a new bug to get this included into the API. Mark your bug as dependent on it. This should not be part of the test.

>+  // Get contents of locationbar and compare it to expected result
>+  controller.assertValue(locationBar.urlbar, docSelection);

I thought that wasn't working yesterday and a timeout before fixed it? I would propose to use the waitForEval function.

Further we need a teardownModule function which makes sure that the context menu has really been closed. Otherwise following tests will fail due to missing focus.
Attachment #452069 - Flags: review?(hskupin) → review-
(In reply to comment #3)
> >+var setupModule = function(module)
> >+{
> >+  module.controller = mozmill.getBrowserController();
> >+  module.locationBar =  new ToolbarAPI.locationBar(controller);
> 
> Remove all module instances and the parameter too. Place the opening { bracket
> in the same line as the function name.

 I'm not sure what you mean by "remove all module instances and the parameter too" here.
 
> >+  // Clear the locationBar and rightclick in it for context menu
> >+  locationBar.clear();
> >+  controller.rightclick(locationBar.urlbar, 150, 0);
> 
> Instead of using a hard-coded value we should retrieve the boundaries of the
> elements box and compute the center position. 

 I'm not trying to click on the center though. I'm trying to click anywhere in the urlbar. It's just that if you use 0,0 (default) values, it doesn't actually click within the urlbar but near/on top of the favicon/ssl notification area.

 That input box has no id so I'm not aware of a non-hacky way of getting its size.
 
> >+  // Hack to paste from contextmenu in urlbar since it has no id
> >+  controller.click(new elementslib.Lookup(controller.window.document, '/id("main-window")/id("navigator-toolbox")/id("nav-bar")/id("urlbar-container")/id("urlbar")/anon({"class":"autocomplete-textbox-container"})/anon({"anonid":"textbox-input-box"})/anon({"anonid":"input-box-contextmenu"})/{"label":"Paste","accesskey":"p","cmd":"cmd_paste"}'));
> 
> Please file a new bug to get this included into the API. Mark your bug as
> dependent on it. This should not be part of the test.

 But that means I won't be able to get this checked in until I wait for someone else to add it to the API. Do we need to add urlbar context menu work to the API if we're only going to use it two or three times in automation?
 
> >+  // Get contents of locationbar and compare it to expected result
> >+  controller.assertValue(locationBar.urlbar, docSelection);
> 
> I thought that wasn't working yesterday and a timeout before fixed it? I would
> propose to use the waitForEval function.

 This patch was submitted before I find out about the timing issue.

 I'm currently blocked on using waitForEval because assertValue takes an object and a string and compares whereas waitForEval is not as straightforward with which to work. I need someone to walk me through the right way to get waitForEval to work to compare the contents of the urlbar with my docSelection variable (which is what I pasted into it). I get nothing but errors when I try to use it.
 
> Further we need a teardownModule function which makes sure that the context
> menu has really been closed. Otherwise following tests will fail due to missing
> focus.

 I'm not sure how to check that the context menu has been closed.
(In reply to comment #4)

>  I'm currently blocked on using waitForEval because assertValue takes an object
> and a string and compares whereas waitForEval is not as straightforward with
> which to work. I need someone to walk me through the right way to get
> waitForEval to work to compare the contents of the urlbar with my docSelection
> variable (which is what I pasted into it). I get nothing but errors when I try
> to use it.

I can probably give you a hand with this part--I had to work with waitForEval for my last patch.
Depends on: 573095
(In reply to comment #4)
> (In reply to comment #3)
> > Remove all module instances and the parameter too. Place the opening { bracket
> > in the same line as the function name.
> 
>  I'm not sure what you mean by "remove all module instances and the parameter
> too" here.

 Figured it out. Done.

> > >+  // Hack to paste from contextmenu in urlbar since it has no id
> > >+  controller.click(new elementslib.Lookup(controller.window.document, '/id("main-window")/id("navigator-toolbox")/id("nav-bar")/id("urlbar-container")/id("urlbar")/anon({"class":"autocomplete-textbox-container"})/anon({"anonid":"textbox-input-box"})/anon({"anonid":"input-box-contextmenu"})/{"label":"Paste","accesskey":"p","cmd":"cmd_paste"}'));
> > 
> > Please file a new bug to get this included into the API. Mark your bug as
> > dependent on it. This should not be part of the test.

 Done.
(In reply to comment #4)
>  I'm not trying to click on the center though. I'm trying to click anywhere in
> the urlbar. It's just that if you use 0,0 (default) values, it doesn't actually
> click within the urlbar but near/on top of the favicon/ssl notification area.
> 
>  That input box has no id so I'm not aware of a non-hacky way of getting its
> size.

We do not know the size of the browser window. So using a value like 150 could already be outside of the clickable area. Looks like I will also add an entry to the shared module's getElement function which will return the input box itself.

>  But that means I won't be able to get this checked in until I wait for someone
> else to add it to the API. Do we need to add urlbar context menu work to the
> API if we're only going to use it two or three times in automation?

All element creation calls should be handled in the shared module. It will be done in the next days. Meanwhile you can already work on another test in your queue.

>  I'm currently blocked on using waitForEval because assertValue takes an object
> and a string and compares whereas waitForEval is not as straightforward with
> which to work. I need someone to walk me through the right way to get
> waitForEval to work to compare the contents of the urlbar with my docSelection
> variable (which is what I pasted into it). I get nothing but errors when I try
> to use it.

The following should work without testing it:

waitForEval("subject.urlbar.getNode().value == subject.selectedText", gTimeout, 100, {urlbar: locationBar.urlbar, selectedText: docSelection})

>  I'm not sure how to check that the context menu has been closed.

You will only have to call locationBar.closeContextMenu when the API is ready.
Rev2 with most of the fixes asked for. Waiting for Geo's Places shared module change and Henrik's Toolbar one.
Attachment #452069 - Attachment is obsolete: true
Attachment #452339 - Flags: review?(hskupin)
Attached file Rev 3 of patch. (obsolete) — 
This rev fixes a bad comment in the last one, uses Geo's new changes in the Places shared module, and removes the trim() on the grabbed text that was causing the test to fail in Windows because the copy to the clipboard actually grabs a trailing space on Windows.
Attachment #452339 - Attachment is obsolete: true
Attachment #452339 - Flags: review?(hskupin)
Al the new element getters are in place now with bug 573095. Please update the test. Example how to use those methods see firefox/helperClasses/testToolbarAPI.js
Attached patch Rev 4 of patch — — Splinter Review 
Updated to use Henrik's toolbar API updates to allow for access to urlbar input box and context menu items. This should be final.

Tested on nightly 1.9.3 build on OS X 10.6, Windows 7, and Ubuntu 10.4.
Attachment #452410 - Attachment is obsolete: true
Comment on attachment 452831 [details] [diff] [review]
Rev 4 of patch

Don't forget to ask for review once a patch has been uploaded. Putting on my review queue.
Attachment #452831 - Attachment is patch: true
Attachment #452831 - Attachment mime type: application/octet-stream → text/plain
Attachment #452831 - Flags: review?(hskupin)
Comment on attachment 452831 [details] [diff] [review]
Rev 4 of patch

Overall this patch looks good. There are only some smaller nits here which I will fix before the check-in.

>+// Include necessary modules
>+const RELATIVE_ROOT = '../../shared-modules';
>+const MODULE_REQUIRES = ['ToolbarAPI', 'UtilsAPI', 'PlacesAPI'];

We should have an alphabetical order of the used shared modules.

>+const gDelay = 200;
>+const gTimeout = 5000;

gDelay isn't used and can be removed. For the global timeout please use capital letters, because it's a constant.

>+const localTestFolder = collector.addHttpResource('../test-files/');

Same here.

>+var setupModule = function(module) {
>+  controller = mozmill.getBrowserController();
>+  locationBar =  new ToolbarAPI.locationBar(controller);
>+  
>+   // Clear complete history so we don't get interference from previous entries
>+    PlacesAPI.removeAllHistory();

There is an indentation issue.

>+/**
>+ * Grab some text from a web page and then paste it into the toolbar
>+ *
>+ */
>+
>+var testPasteLocationBar = function() {

No need for an empty line between the comment and the function body.

>+  // Focus on page, select text and copy to clipboard
>+  ipsumLocation = new elementslib.ID(controller.window.document, 'ipsum')
>+  controller.doubleClick(ipsumLocation)

Both lines miss the semicolon at the end.

>+  // Control/command and c to copy "what" to clipboard  
>+  controller.keypress(null, 'c', {accelKey: true});

Well, 'what' is the old value and now we are using 'ipsum'.

>+  // Get contents of locationbar and compare it to expected result  
>+  controller.waitForEval("subject.urlbar.getNode().value == subject.selectedText", gTimeout, 100, {urlbar: locationBar.urlbar, selectedText: docSelection}); 

.getNode() can be a part of the object and doesn't have to be in the eval expression. Also move the object parameter to its own line in the next test.

>+/**
>+ * Map test functions to litmus tests
>+ */
>+// testAccessLocationBarHistory.meta = {litmusids : [8443};

For new tests we don't add it.

Further I miss the teardownModule function, which should be used to make sure the context menu has been closed.
Attachment #452831 - Flags: review?(hskupin) → review+
Landed on all branches:
http://hg.mozilla.org/qa/mozmill-tests/rev/43a3c1310d31
http://hg.mozilla.org/qa/mozmill-tests/rev/a7f2cc1568b5
http://hg.mozilla.org/qa/mozmill-tests/rev/14acc3e342ba

Al, can you also upload that file to our litmus-data repository and update the Litmus tests? Thanks.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-litmus?
Resolution: --- → FIXED
File has been added to litmus and 3.5, 3.6, and 3.7 testcases updated. I see you've already added a note to them that they are covered by this automated case.

The automation doesn't work on 3.5 for come reason though.
Oh, Litmus testfiles checkin is changeset 10:113ad2ab5c7f.
(In reply to comment #15)
> The automation doesn't work on 3.5 for come reason though.

I have tested it and it passed for me. Are you sure you have updated your local branch before running the test with Shiretoko? Can you please paste the failure message?
I didn't run it after I changed to use the new libraries. There was no failure message. It just wasn't copying the selected text to clipboard last week on OS X.
Can you please repeat it on your box? Just to prove we have checked in a non-failing test on 1.9.1.
Attached file Failure on 1.9.1 — 
It fails on 1.9.1. It doesn't even load the test page. Here is the log.
Attachment #453597 - Attachment mime type: application/octet-stream → application/text
Attachment #453597 - Attachment mime type: application/text → text/plain
Ok, I can see this now too. The problem was that I run the tests for default and 1.9.2 and already had the expected text in the clipboard. Al, we would have to do three more steps here:

1. Create an helper function in UtilsAPI to clear the clipboard
2. Call this helper function in setupModule
3. Check why Cmd+C doesn't copy the text and fix it

Backed out on mozilla1.9.1:
http://hg.mozilla.org/qa/mozmill-tests/rev/ae8c1ba2a416
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Any update on this bug Al? The dependency has been fixed a long time ago. I would really like to see this fixed and a test for 3.5.
Component: Location Bar → Mozmill Tests
Flags: in-litmus?
Product: Firefox → Testing
QA Contact: location.bar → mozmilltests
Version: 3.6 Branch → unspecified
Summary: [mozmill] Context menu: Paste string into location bar → Context menu: Paste string into location bar
I was looking at checking it in for default and 1.9.2 next week. I haven't figured out why it doesn't work on 1.9.1.
Comment on attachment 488094 [details] [diff] [review]
Patch to use utils clear clipboard function for default branch

Looks fine. I'll go ahead and land it.

Couple of process nitpicks re: reviewer, commit message. I'll shoot you a quick message offline.
Attachment #488094 - Flags: review? → review+
Bah, I blew it on this review. 

I missed the absent semicolon (it's optional, but it's good practice to always use it) plus there was some trailing whitespace introduced.

This patch is a quickie that fixes both.
Attachment #488113 - Flags: review?(anthony.s.hughes)
Attachment #488113 - Flags: review?(anthony.s.hughes) → review+
Doh. Komodo introduces the whitespace because it does auto-indentation. I didn't catch that.
The 1.9.2 version without extra whitespace and with semicolon.
Attachment #488225 - Flags: review?(gmealer)
Depends on: 609664
Comment on attachment 488225 [details] [diff] [review]
Patch to use utils clear clipboard function for 1.9.2 branch

r+ Looks fine, I'll land it presently.
Attachment #488225 - Flags: review?(gmealer) → review+
This is a port for 1.9.1. I'll actually need to *upport* this to 1.9.2 and default as it is much cleaner (with the new menu api support).
Attachment #489351 - Flags: review?(gmealer)
Comment on attachment 489351 [details] [diff] [review]
Port of testPasteLocationBar.js to mozilla 1.9.1

>+/** Any copyright is dedicated to the Public Domain.
>+ * http://creativecommons.org/publicdomain/zero/1.0/
>+ */

Please don't use Public Domain. It's something we have reverted a while back. Stick to our MPL and put your name in.

>+  // Get the urlbar input box, right click in it, and select paste from context menu
>+  var input = locationBar.getElement({type: "urlbar_input"});
>+  controller.rightClick(input);
>+  var contextMenuEntry = locationBar.getElement({type: "contextMenu_entry", subtype: "paste"});
>+  controller.click(contextMenuEntry);

This part can also use the Menu API.
Updated to address Henrik's comments.
Attachment #489351 - Attachment is obsolete: true
Attachment #489605 - Flags: review?(gmealer)
Attachment #489351 - Flags: review?(gmealer)
Hold it. Grabbed the wrong file. Fixing.
I had somehow not exported tip correctly. Now correct.
Attachment #489605 - Attachment is obsolete: true
Attachment #489608 - Flags: review?(gmealer)
Attachment #489605 - Flags: review?(gmealer)
Comment on attachment 489608 [details] [diff] [review]
Port of testPasteLocationBar.js to mozilla 1.9.1

>+ * The Original Code is MozMill Test code.
>+ *
>+ * The Initial Developer of the Original Code is
>+ * Al Billings <abillings@mozilla.com>.

Initial dev should be "Mozilla Foundation" for anything we do in-house (this doesn't apply to outside contributors who establish new files).

>+ *
>+ * Portions created by the Initial Developer are Copyright (C) 2010
>+ * the Initial Developer. All Rights Reserved.
>+ *
>+ * Contributor(s):

...but you should go ahead and add yourself as the initial contributor.

>+var setupModule = function(module) {

We've abandoned the var foo = function() thing because it doesn't give good info back to the debugger and other tools.  Also, don't put in the module parameter since it won't actually get used. (I know older files are inconsistent on this, so there was no good way to know--it's going in the new style guide).

Instead, should be:

function setupModule() {

>+  controller = mozmill.getBrowserController();
>+  locationBar =  new toolbars.locationBar(controller);

Whitespace between = and new.

>+var teardownModule = function() {

per above, should be function teardownModule() {

>+var testPasteLocationBar = function() {

...and function testPasteLocationBar() {

>+  // Get contents of locationbar and compare it to expected result  
>+  controller.waitForEval("subject.urlbar.value == subject.selectedText", TIMEOUT, 100,
>+                         {urlbar: locationBar.urlbar.getNode(), selectedText: docSelection});
>+}

Similarly, we deprecated waitForEval (and assertJS).  Instead:

controller.waitFor(function () {
  return locationBar.urlbar.getNode().value == docSelection;
}, "Contents of location bar match selected text", TIMEOUT, 100);

Make sure you give it a quick run after changes just to make sure I didn't screw up your waitFor for you. :)
Attachment #489608 - Flags: review?(gmealer) → review-
Updated for Geo's suggested changes.
Attachment #489608 - Attachment is obsolete: true
Attachment #489974 - Flags: review?(gmealer)
(In reply to comment #38)
> Initial dev should be "Mozilla Foundation" for anything we do in-house (this
> doesn't apply to outside contributors who establish new files).

To be correct it should be "the Mozilla Foundation".

> >+ * Contributor(s):
> 
> ...but you should go ahead and add yourself as the initial contributor.

... with a 2 space indentation.

> >+var setupModule = function(module) {
> 
> We've abandoned the var foo = function() thing because it doesn't give good
> info back to the debugger and other tools.  Also, don't put in the module
> parameter since it won't actually get used. (I know older files are
> inconsistent on this, so there was no good way to know--it's going in the new
> style guide).

I wouldn't bother with all those changes. Only doing that on 1.9.1 will give those tests a completely different style as what we have on default and 1.9.2. Not really sure at this point if that is a benefit.
Can you two talk and agree on the official feedback? I've already submitted an updated patch based on Geo's feedback that you are now commenting on, Henrik.

Oh, and I looked through the existing cases and people have put "Mozilla Foundation" and not "the Mozilla Foundation" so I did the former in my update.
Comment on attachment 489974 [details] [diff] [review]
Port of testPasteLocationBar.js to mozilla 1.9.1

Hah, sorry about that, Al and Henrik. Henrik wasn't around when I did the review so I did a quick poll of the team and then punted on the "additional changes" decision.

Henrik, Al already did the changes per my code review. Since we're unlikely to backport to 1.9.1 I think it's six of one and half-dozen of the other and I'd prefer to just take the latest patch.

Al, I'll adjust the indent and the attribution (if necessary) before landing. It probably is "the Mozilla Foundation" though, and I probably did lead you astray. It certainly reads better that way.
Attachment #489974 - Flags: review?(gmealer) → review+
It does read better that way, which is why it is weird that "the" is omitted in other checked in cases...

Thanks.
(In reply to comment #43)
> It does read better that way, which is why it is weird that "the" is omitted in
> other checked in cases...

Other and specifically older tests will be updated by Anthony soon. The decision in using "the" came later in.
Anthony, I missed the close delimiter on Al's email addy. This fixes it, quickie review?
Attachment #490245 - Flags: review?(anthony.s.hughes)
Comment on attachment 490245 [details] [diff] [review]
Added ">" to the end of Al's email address

I don't think a review is necessary in these cases.  It creates needless overhead.  Simply attach the patch to the bug and check it in.  However if that's not agreeable we can keep up the strict patch > review > checkin procedure.

r+ anyway.
Attachment #490245 - Flags: review?(anthony.s.hughes) → review+
Generally agree with you--in fact, in past teams we've had a trivial changes don't need patches, where trivial == whitespace, comment, or typo.

OTOH, since I don't know we have that here, was going to bring it up with Henrik and figured I'd do this one the official way.  Thanks!
er, don't need reviews that is, not don't need patches :)
Updated all three litmus testcases to be consistent and point to automation file as well as loading test files from the litmus-file repository.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
(In reply to comment #51)
> Updated all three litmus testcases to be consistent and point to automation
> file as well as loading test files from the litmus-file repository.

Thanks. Can you also please update the Litmus 4.0 column with the Litmus test id?
That was done yesterday (already).
Since its check-in on Friday this test is broken on Linux for 3.5 builds:

http://mozmill-release.brasstacks.mozilla.com/#/general/failure?branch=All&platform=All&test=firefox%2FtestAwesomeBar%2FtestPasteLocationBar.js&func=testPasteLocationBar
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I'll investigate this tomorrow.
Running this on normal Ubuntu 10.04 with either 1.9.1.15 (release) or the nightly 1.9.1.16pre, it passes fine. I ran it multiple times with each.

Looking at brasstacks, if I'm reading it right, this is only failing on 64-bit Ubuntu 10.04. Is this correct?
Running this on Ubuntu 10.04 64-bit with the nightly 1.9.1 build for 64-bit passes as well.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16pre) Gecko/20101115 Shiretoko/3.5.16pre

I'm not sure how to fix a failure that I cannot reproduce. Which machine is this failing on? I'll look at it in the 64-bit Ubuntu VM there.
It happens for both the 32bit and 64bit Ubuntu machines. But as I can see also other tests related to focus are failing. So a manual test-run on qa-horus after the todays scheduled one could be helpful.
Move of Mozmill Test related project bugs to newly created components. You can
filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.
Product: Testing → Mozilla QA
Al, any update on this bug for 1.9.1? I just got it while running release tests on Ubuntu 32bit. If we can't fix it we will have to backout the test.
It works fine on my machine. Have you seen it fail anywhere but qa-horus and qa-set (i.e. have you run it on your own machine and seen it fail)? 

Are the other focus tests still failing as well?
I did no test-runs for this particular test. But you can always use qa-set or qa-horus to check how to reproduce a failure. Nothing else fails and well, I think it is somehow related to how text gets copied and/or pasted.
Status: REOPENED → ASSIGNED
I'm not sure how I'm supposed to debug this when it works fine on my machine. It's copy and paste...
You can debug on qa-horus or qa-mozmill (latter's probably a preferred sandbox, if you can dupe it there).  

Re: debugging techniques, controller.window.alert() and dump() can both be useful to print interim values. In particular, it'd be really instructive to dump() both docSelection and the urlBar.getNode().value it's being compared with. One protip, dump them like:

dump("***" + docSelection + "***");

...as that tends to expose any added whitespace before/after the value (you'll see the gap between value and the ***s). IIRC, whitespace was the issue one similar test had before.

Also, one other difference between the tests as run is that the qa-horus ones run in sequence and you're probably trying one test at a time to duplicate it. It's possible it's an error that only happens when you run in sequence.
(In reply to comment #64)
> Re: debugging techniques, controller.window.alert() and dump() can both be
> useful to print interim values. In particular, it'd be really instructive to
> dump() both docSelection and the urlBar.getNode().value it's being compared

Yeah, dump doesn't move the focus, which could be important here too.

> dump("***" + docSelection + "***");

And add a "\n" at the end. Sadly it's not done automatically.
Running the failing test by itself in the 32-bit Ubuntu VM (where it failed yesterday), it passes. So the test, itself, is not broken.

I'm not doing a BFT run to see if it fails in series with the other tests. If it fails there, I'm not sure if it is really *my* test that's at issue and how we should proceed. We don't have a checkin requirement of "Make sure your test passes and then do a test run to make sure it passes in our current hardcoded series of runs." It seems like this is impetus to fix our teardown/cleanup problems.
It fails in the BFT run so this is a problem with our testruns not isolating tests.

See my log at http://mozilla.pastebin.com/D9VtRqSS.

It runs after testFaviconInAutocomplete.js and others. One of them seems to be borking my test somehow on 3.5.
(In reply to comment #67)
> It fails in the BFT run so this is a problem with our testruns not isolating
> tests.
> 
> See my log at http://mozilla.pastebin.com/D9VtRqSS.
> 
> It runs after testFaviconInAutocomplete.js and others. One of them seems to be
> borking my test somehow on 3.5.

This may be related to whatever is causing testPasswordNotSaved to fail (bug 614973) -- which also only occurs on the Ubuntu32 VM.
Ok, so I would say lets close this bug then and file a new one for the failure on Linux. We can investigate the problem over there.
All right. I'm going to try to come up with a minimal repro case of tests in a row that lead to this failure on my Ubuntu VM.
This also failed today when testing the firefox 4.0 beta 8 candidate build on linux:

http://mozmill-release.brasstacks.mozilla.com/#/general/report/e03c0b4816e1982da6bb246247006eb9

Al, I would really appreciate it, if we could get progress on that failure, and even get this moved out to a new bug, as already proposed on comment 69. If you feel that you aren't able to fix this, please tell so someone else can pick it up. This failure is already showing up too long. Thanks.
I think we can resolve this bug.  The original intent of this bug was to get a test checked in for "Paste string into location bar".  That was achieved long ago. The fact that this test fails can be moved over to a new bug.
Nothing happened on this bug for one more month. I have created bug 624682 for the test failure now.

Closing this bug.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: