Closed
Bug 1054411
Opened 10 years ago
Closed 10 years ago
cache2 automation: browser_keywordSearch.js tries to connect to google.com with cache2 enabled
Categories
(Firefox :: Search, defect)
Firefox
Search
Tracking
()
Tracking | Status | |
---|---|---|
firefox32 | --- | fixed |
firefox33 | --- | fixed |
firefox34 | --- | fixed |
firefox-esr24 | --- | unaffected |
firefox-esr31 | --- | fixed |
People
(Reporter: jduell.mcbugs, Assigned: MattN)
References
Details
Attachments
(1 file)
1.04 KB,
patch
|
MattN
:
review+
jduell.mcbugs
:
feedback+
|
Details | Diff | Splinter Review |
See 'bc1' failures in this try run:
https://tbpl.mozilla.org/?tree=Try&rev=a1ea7549c4fd
I glanced at the code but see nothing obvious. The test puts some text in the URI bar and then focuses it. I think we may need some help from the Firefox team to quickly understand how that winds up interacting with the cache in some way that doesn't cause external network traffic in cache1 but does in cache2.
Reporter | ||
Comment 1•10 years ago
|
||
Matt, looks like you've touched this test (so did Mike de Boer but he's out until Sept 15). Any idea how this test interacts with the HTTP cache, and why using the new cache2 causes the test to try to contact google.com?
This is blocking the new HTTP cache from landing on release, so fairly urgent.
Flags: needinfo?(MattN+bmo)
Assignee | ||
Comment 2•10 years ago
|
||
It looks like the HTTP request isn't being cancelled like related tests do. I can't repro locally on my opt build so I'm testing in my debug build now.
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
Flags: needinfo?(MattN+bmo)
Assignee | ||
Comment 3•10 years ago
|
||
If I switch executeSoon(nextTest); to setTimeout(nextTest, 2000); the tests fail locally. The cleanup of the tab happens so quickly on my machine that it doesn't fail normally.
This should be a one line patch… coming up
Assignee | ||
Comment 4•10 years ago
|
||
I checked that the other forks of this test already were doing req.cancel but this file didn't get the enhancement.
https://mxr.mozilla.org/mozilla-central/search?string=info%28%22Actual%20URI%3A
Jason, if you're okay with this then I'll land it.
I don't know why the new cache affects this but it seems like this patch is the right thing to do regardless. You may want to dig deeper into the different cache behaviour.
Attachment #8473826 -
Flags: review+
Attachment #8473826 -
Flags: feedback?(jduell.mcbugs)
Assignee | ||
Updated•10 years ago
|
Iteration: --- → 34.2
Points: --- → 1
Component: Networking: Cache → Search
Flags: firefox-backlog+
Product: Core → Firefox
Updated•10 years ago
|
QA Whiteboard: [qa?]
Assignee | ||
Updated•10 years ago
|
QA Whiteboard: [qa?] → [qa-]
Reporter | ||
Comment 5•10 years ago
|
||
Comment on attachment 8473826 [details] [diff] [review]
Cancel the HTTP requests. r=adw (in-person)
Review of attachment 8473826 [details] [diff] [review]:
-----------------------------------------------------------------
Thanks for the quick turnaround. If you're happy with this, I'm good with it.
Attachment #8473826 -
Flags: feedback?(jduell.mcbugs) → feedback+
Assignee | ||
Comment 6•10 years ago
|
||
Whiteboard: [fixed-in-fx-team]
Comment 7•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/16df0245bd97
https://hg.mozilla.org/releases/mozilla-beta/rev/6dec02f8d0ea
https://hg.mozilla.org/releases/mozilla-esr31/rev/9dd934d72ed0
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
status-firefox34:
--- → fixed
status-firefox-esr24:
--- → unaffected
status-firefox-esr31:
--- → fixed
Comment 8•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 34
You need to log in
before you can comment on or make changes to this bug.
Description
•