Closed Bug 570266 Opened 15 years ago Closed 12 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
5.95 KB, 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) — — 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) — — 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 — — 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: 12 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: