Notification when a new tab is opened

VERIFIED FIXED

Status

Fennec Graveyard
General
VERIFIED FIXED
8 years ago
7 years ago

People

(Reporter: Milos, Assigned: vingtetun)

Tracking

Details

(Whiteboard: [fennecb5testday])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

8 years ago
When a user clicks on a link with "_blank" target, fennec opens new tab silently. If a user does not have left side panel opened when opening a new tab, there is no chance for it to know that the tab was opened. Therefore, we need some notification that the new tab was opened.
(Reporter)

Updated

8 years ago
Whiteboard: [fennecb5testday]
We do not show the notification if the current window _is_ the new tab. This is by design.
(Reporter)

Comment 2

8 years ago
Nope, I'm talking about the case when the new tab when you click on the link with _blank target, and as far as I could see, that tab is not active once you open it.
Assignee: nobody → mbrubeck
We only show the "Newt tab" notification when a tab was opened in the background. If a new tab is opened and becomes the active tab, do we need a notification?
Right now there is no indication when a new tab has opened in the foreground.  This means that the user doesn't know that the old tab is still open, or why the "back" command doesn't work.

Possible improvements:

1) When "back" is pressed on the first page in a child tab, return to the parent/opener tab if possible (Android does this).

2.a) Display an animation when opening a link in a new tab (Android and iPhone do this), or

2.b) display a notification popup saying a new tab has opened.

Comment 5

8 years ago
Created attachment 445153 [details]
Real world example for my comment

Comment 6

8 years ago
Yeah. I agree with mbrubeck.
I would like to present a real world example here. 
1)Login to your yahoomail account. When you login, you see a "My Yahoo" link on the top right (as seen in my attachment).
2)Click on that link. It opens a new tab. 

Now, in Fennec, a user wont know that its a new tab. So he will try to go to the control side bar and try to go back. But back wont be enabled as its a new tab. Here the user will get confused as to why the back command doesnt work. 

So probably I think improvement[2.a] provided by mbrubeck in comment can be a design option to consider.
Created attachment 445325 [details] [diff] [review]
Patch

This patch use an observer to avoid adding browser-ui.js code to browser.js.
Attachment #445325 - Flags: review?(mbrubeck)
Attachment #445325 - Flags: review?(mark.finkle)
Comment on attachment 445325 [details] [diff] [review]
Patch

The code looks fine to me, though maybe we want new tabs in the foreground to have a different message than new tabs in the background.

And I'd like to hear from Madhava if he prefers some other way to let users know when they have switched tabs.
Attachment #445325 - Flags: review?(mbrubeck) → review+
Comment on attachment 445325 [details] [diff] [review]
Patch

Waiting for Madhava's input
Attachment #445325 - Flags: review?(mark.finkle) → review+
Duplicate of this bug: 541475
Madhava in duplicate bug 541475:
> A transient indicator is appropriate here;
> the question is just where to put it.
Assignee: mbrubeck → nobody
OS: Linux → All
Hardware: x86 → All
I just looked at this patch again, wondering if we needed more work before landing. I notice that we are firing a notification for a "new-tab" and I wonder why we didn't use the "TabOpen" event instead.
Created attachment 488182 [details] [diff] [review]
Patch v0.2

This bug was completely out of my mind, thanks for resurecting it.
I've rebased the patch on the trunk and replace "new-tab" by "NewTab", also the reason why we're not reacting to TabOpen is because we're already in the TabOpen and I don't know a way to know if the tab is opened by a click or not at this time.
Assignee: nobody → 21
Attachment #445325 - Attachment is obsolete: true
Attachment #488182 - Flags: review?(mark.finkle)
Comment on attachment 488182 [details] [diff] [review]
Patch v0.2

>diff --git a/chrome/content/browser-ui.js b/chrome/content/browser-ui.js

>       case "TabOpen":
>       {
>-        let [tabsVisibility,,,] = Browser.computeSidebarVisibility();
>-        if (!(tabsVisibility == 1.0) && Browser.selectedTab.chromeTab != aEvent.originalTarget)
>-          NewTabPopup.show(aEvent.originalTarget);
>+        if (Browser.selectedTab.chromeTab != aEvent.originalTarget)
>+          Services.obs.notifyObservers(aEvent.originalTarget, "NewTab", null);

Why can't NewTabPopup listen for the "TabOpen" and do this same check?
Attachment #488182 - Flags: review?(mark.finkle) → review-
Created attachment 488200 [details] [diff] [review]
Patch v0.3

There is no good reasons
Attachment #488182 - Attachment is obsolete: true
Attachment #488200 - Flags: review?(mark.finkle)
Comment on attachment 488200 [details] [diff] [review]
Patch v0.3


>-    let event = document.createEvent("Events");
>-    event.initEvent("TabOpen", true, false);
>+    let showNewTabPopup = (!aBringFront || params.showNewTabPopup);
>+    let event = document.createEvent("UIEvents");
>+    event.initUIEvent("TabOpen", true, false, window, showNewTabPopup);
>     newTab.chromeTab.dispatchEvent(event);

>       let owner = isExternal ? null : Browser.selectedTab;
>-      let tab = Browser.addTab("about:blank", true, owner);
>+      let tab = Browser.addTab("about:blank", true, owner, { showNewTabPopup: true });

showNewTabPopup -> getAttention
Attachment #488200 - Flags: review?(mark.finkle) → review+
http://hg.mozilla.org/mobile-browser/rev/67882b70bd4d
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
verified FIXED on builds:
Mozilla/5.0 (Maemo; Linux armv71; rv:2.0b8pre) Gecko/20101105 Namoroka/4.0b8pre Fennec/4.0b2pre

and

Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101105 Namoroka/4.0b8pre Fennec/4.0b2pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.