Closed Bug 1093161 Opened 10 years ago Closed 10 years ago

[e10s] Searching from a new tab's address bar does not work the first time when e10s is enabled

Categories

(Firefox :: Search, defect)

Product:
Firefox
Component:
Search
Type:
defect
Priority:
Not set
Severity:
normal
Points:
2

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 36
Iteration:
36.2
Tracking Flags:
Tracking Status
e10s m5+ ---

People

(Reporter: martin, Assigned: mossop)

References

(Blocks 1 open bug)

Details

(Keywords: dogfood, regression, reproducible)

Attachments

(1 file)

patch
(deleted), patch
ttaubert
: review+
Details | Diff | Splinter Review
Story Enter a search text into the urlbar Google is selected in seach bar Result Errorpage, Message URL is not valid Expected Result Search & Display of seach results with searchengine currently selected in searchbar Reproducible: Always on Build Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141103030205 CSet: 0b81c10a9074
tracking-e10s: --- → ?
I can reproduce this bug. It only happens the first time I try to search in a tab. The second time I try to search in a tab, the search succeeds.
Status: UNCONFIRMED → NEW
Component: General → Search
Ever confirmed: true
OS: Windows 8.1 → All
Hardware: x86 → All
This bug is a regression in Nightly 36 build 2014-10-31. I bisected the regression to this pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=17bae3d258dd&tochange=c82688553793 * Dave: could this be a regression from your fix for bug 1077738 or bug 1090456?
Blocks: fxe10s
Flags: needinfo?(dtownsend+bugmail)
Keywords: regression, reproducible
Summary: [e10s] typing a search into the urlbar does not work on current nightly build with e10s enabled → [e10s] Searching from a new tab's address bar does not work the first time when e10s is enabled
I don't think so. Can we bisect further than that?
Flags: needinfo?(dtownsend+bugmail)
Personally, I found this annoying enough that I've disabled E10s on Nightly.
Keywords: dogfood
Regression window(fx) Good: https://hg.mozilla.org/integration/fx-team/rev/5a9f63201e5c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141029121209 Bad: https://hg.mozilla.org/integration/fx-team/rev/8c589a6d637e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141029132706 Puahlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=5a9f63201e5c&tochange=8c589a6d637e Regressed by: 8c589a6d637e Dave Townsend — Bug 1075658: Make browser.loadURI synchronously update the browser remoteness. r=ttaubert
Blocks: 1075658
Flags: needinfo?(dtownsend+bugmail)
Keywords: regressionwindow-wanted
Huh.
Assignee: nobody → dtownsend+bugmail
Flags: needinfo?(dtownsend+bugmail)
Status: NEW → ASSIGNED
Iteration: --- → 36.2
Points: --- → 2
Flags: qe-verify-
Flags: firefox-backlog+
Attached patch patch (deleted) — — Splinter Review
Dumb typo basically, load flags instructing the docshell to use fixup weren't making it through to the child process. Adds a test that the load flags make it through.
Attachment #8517877 - Flags: review?(smacleod)
Attachment #8517877 - Flags: review?(smacleod) → review+
https://hg.mozilla.org/mozilla-central/rev/2b25041d6c06
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Works for me: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141107030202 CSet: 17e190839086
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: