If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Middle-clicking on the items in the History subview should open them in a new tab

RESOLVED FIXED in Firefox 28

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: jaws, Assigned: jaws)

Tracking

Trunk
Firefox 28
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Australis:P3][Australis:M9])

Attachments

(1 attachment)

Middling-clicking on the items in the History subview should open them in a new tab
Summary: Middling-clicking on the items in the History subview should open them in a new tab → Middle-clicking on the items in the History subview should open them in a new tab
Created attachment 818517 [details] [diff] [review]
Patch
Attachment #818517 - Flags: review?(mdeboer)
We don't need to do anything for Recently Closed Tabs or Recently Closed Windows since they have their own opening semantics (tabs reopen as new tabs, and windows reopen as a new window).
Comment on attachment 818517 [details] [diff] [review]
Patch

Review of attachment 818517 [details] [diff] [review]:
-----------------------------------------------------------------

I checked if 'click' and 'command' are not both fired when a history item is clicked. They are not, so this is ready to roll.

Thanks for fixing this!

::: browser/components/customizableui/src/CustomizableWidgets.jsm
@@ +82,5 @@
>                let item = doc.createElementNS(kNSXUL, "toolbarbutton");
>                item.setAttribute("label", title || uri);
>                item.setAttribute("tabindex", "0");
> +              item.addEventListener("command", function (aEvent) {
> +                onHistoryVisit(uri, aEvent, item);

what I find fascinating (and not related to this bug/ patch) is that we use `item` inside a closure. Is it because `item` is block-scoped that it doesn't always reference to the last set `item` when the loop terminated?

It's just a pattern that intrigues me as I've been trained to call the alarm when spotted.

> I just checked this in the Web Console and the theory above is true. Awesome, long live block scoping!
Attachment #818517 - Flags: review?(mdeboer) → review+
Thanks for the quick review!

https://hg.mozilla.org/projects/ux/rev/777283896d61
Whiteboard: [Australis:P3][Australis:M?] → [Australis:P3][Australis:M9][fixed-in-ux]
This patch also needs to be merged to m-c.
Flags: needinfo?(jaws)
Nevermind, I shouldn't look at BZ when I'm sleep deprived. This patch only touched CustomizableWidgets.jsm.
Flags: needinfo?(jaws)

Comment 7

4 years ago
https://hg.mozilla.org/mozilla-central/rev/777283896d61
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3][Australis:M9][fixed-in-ux] → [Australis:P3][Australis:M9]
Target Milestone: --- → Firefox 28

Updated

4 years ago
Blocks: 966125

Updated

4 years ago
No longer blocks: 966125
Depends on: 966125
You need to log in before you can comment on or make changes to this bug.