Closed Bug 1313969 Opened 8 years ago Closed 8 years ago

[Follow-up] Ctrl+Click awesomebar entry with "Switch to Tab" doesn't open new tab

Categories

(Firefox :: Search, defect, P2)

51 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 52
Tracking Status
firefox49 --- unaffected
firefox50 --- unaffected
firefox51 --- verified
firefox52 --- verified

People

(Reporter: adw, Assigned: adw)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1296366 +++ Can't push a review request to reviewboard for a bug that's already been closed, so I'm opening a new one. (In reply to Liviu Cirdei [:liviucirdei] from comment #10) > This is fixed only on Mac OS X. > > It's still broken on Windows and Ubuntu (I tested Windows 10 and Ubuntu > 16.04) on both Nightly 52 (Build ID 20161024030205) and Aurora 51 (Build ID > 20161024004016). > > Also on Mac, even if it works, when pressing "Command" key, the "Switch to > tab" text from URL is replaced by the address of the webpage (e.g. > "http://example.com"). Is this intended?
Comment on attachment 8805894 [details] Bug 1313969 - [Follow-up] Ctrl+Click awesomebar entry with "Switch to Tab" doesn't open new tab. https://reviewboard.mozilla.org/r/89508/#review88842 ::: browser/base/content/urlbarBindings.xml:1003 (Diff revision 1) > > return action; > ]]></body> > </method> > > - <field name="_noActionKeys"><![CDATA[ > + <property name="_noActionKeys" readonly="true"> is there a specific reason to convert from field to a property? Is it just to avoid paying the AppConstants price?
The only reason is because now there's logic to it, it's not just a simple value.
Status: NEW → ASSIGNED
Comment on attachment 8805894 [details] Bug 1313969 - [Follow-up] Ctrl+Click awesomebar entry with "Switch to Tab" doesn't open new tab. https://reviewboard.mozilla.org/r/89508/#review88922 well, ok. I honestly don't know if we have guidelines for field VS property, in this case the perf differences are uninteresting. Not that I care that much.
Attachment #8805894 - Flags: review?(mak77) → review+
Pushed by dwillcoxon@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c42b82086c26 [Follow-up] Ctrl+Click awesomebar entry with "Switch to Tab" doesn't open new tab. r=mak
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
Attached patch Aurora 51 patchSplinter Review
Approval Request Comment [Feature/regressing bug #]: One-off searches in awesomebar, bug 1180944. This was already "fixed" and uplifted in bug 1296366, but the fix didn't actually work on Windows and Linux, only Mac. [User impact if declined]: Users on Windows and Linux will see the original bug, bug 1296366: ctrl+clicking on an awesomebar switch-to-tab result doesn't open it in a new tab. [Describe test coverage new/current, TreeHerder]: Manual testing [Risks and why]: Low risk, small patch [String/UUID change made/needed]: None
Attachment #8806229 - Flags: approval-mozilla-aurora?
Comment on attachment 8806229 [details] [diff] [review] Aurora 51 patch Fix a regression related to awesomebar. Take it in 51 aurora.
Attachment #8806229 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
The fix is verified on Nightly 52.0a1 (Build ID 20161101030207). Tested on: * Windows 10 * Windows 7 * Ubuntu 15.04
Thanks Liviu!
The fix is verified on Aurora 51.0a2 (Build ID 20161102004003). I tested on: *Windows 10 *Ubuntu 16.04 *Mac 10.11
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: