Closed Bug 570266 Opened 14 years ago Closed 11 years ago

AddKeywordForSearchField resolves form action URI incorrectly

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 25

People

(Reporter: Gavin, Assigned: smacleod)

References

Details

(Whiteboard: [good first bug][mentor=gavin])

Attachments

(1 file, 2 obsolete files)

Patch
(deleted), patch
Details | Diff | Splinter Review 
It uses the document URI rather than the form's baseURI when calling newURI on the action attribute's value.

(Also it can use the property rather than the attribute, since XPCNativeWrappers mean we don't need to worry about bug 264607.)
Depends on: 566128
It can just use form.mozActionURI once the relevant patch in bug 566128 lands.
Whiteboard: [good first bug]
Target Milestone: --- → Firefox 4.0b4
Target Milestone: Firefox 4.0b4 → ---
(In reply to comment #1)
> It can just use form.mozActionURI once the relevant patch in bug 566128 lands.

FTR: form.mozActionUri was introduced and then removed through bug 607145.
Hey Gavin, this has been marked as a good first bug for some time now but no one's taken it up. Maybe it would do better if it were a mentored bug. What do you think?
Flags: needinfo?(gavin.sharp)
Sure.
Flags: needinfo?(gavin.sharp)
Whiteboard: [good first bug] → [good first bug][mentor=gavin]
Assignee: nobody → smacleod
Attached patch Patch (obsolete) (deleted) — — Splinter Review 

        Attachment #767822 -
        Flags: review?(gavin.sharp)

    
    

    
  
This could be a good opportunity to gain some test-writing experience!

This is testable with a browser-chrome test, I think (https://developer.mozilla.org/en-US/docs/Browser_chrome_tests).

An example of a test that loads a page and tests how chrome interacts with it is http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/browser_bug581947.js. You could create a new test next to that (maybe name it browser_addKeywordSearch.js), have it load a page with a form whose baseURI is non-default, then call  AddKeywordForSearchField directly and check that it creates a keyword with the right URI.

Ping me in person if you want to chat about this more!

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  
New patch including tests.

        Attachment #767822 -
        Attachment is obsolete: true

        Attachment #767822 -
        Flags: review?(gavin.sharp)

        Attachment #768297 -
        Flags: review?(gavin.sharp)

    
    

    
  
Comment on attachment 768297 [details] [diff] [review]
Patch

Looks good! A couple of nits:

>diff --git a/browser/base/content/test/browser_addKeywordSearch.js b/browser/base/content/test/browser_addKeywordSearch.js

This file needs a license header (see https://www.mozilla.org/MPL/license-policy.html). Just use the "public domain" one at https://www.mozilla.org/MPL/headers/.

>+function test() {

>+  gBrowser.selectedBrowser.addEventListener("load", function() {
>+    gBrowser.selectedBrowser.removeEventListener("load", arguments.callee, true);

arguments.callee is deprecated, give the anonymous event handler function a name instead, and just refer to that.

>+      base.appendChild(form);

IIRC the <base> tag is supposed to be standalone in the <head>, and not have any children? It's a bit odd to be inserting the form into it, but I suppose it doesn't matter much.

>+      is(data.spec, expected, "Bookmark spec for search field named " + fieldName + " and baseURI " + baseURI + " incrorect");

typo "incrorect"

>+    for each (let data in testData) {

for...of is the new hotness (preferred over less-standard for each)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of

>+  gBrowser.selectedTab = gBrowser.addTab();

>+  gBrowser.selectedBrowser.addEventListener("load", function() {
>+  }, true);
>+  content.location = "http://example.org/browser/browser/base/content/test/dummy_page.html";

This pattern can lead to some tricky intermittent failures, because the addTab() call triggers a load of about:blank in that tab, which can race with the load of example.org that you trigger later. Your load listener could then run against about:blank instead of the page you're expecting. That may not matter in this particular test (since I don't think you rely on the page contents at all?), but probably worth avoiding lest someone cargo cult it. I think you can fix it by passing the URL you want to load to addTab(), so that it avoids loading about:blank and just loads the right URL directly.

r=me with those comments addressed

        Attachment #768297 -
        Flags: review?(gavin.sharp) → review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch (deleted)
        — 
          — Splinter Review
      

    


  
Patch updated based on Gavin's review.

        Attachment #768297 -
        Attachment is obsolete: true

    
  
Keywords: checkin-needed

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/3fc0f2db4add
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
Depends on: 891500

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: