Closed Bug 1263155 Opened 10 years ago Closed 3 years ago

Notification popups disappear off screen

Categories

(Toolkit Graveyard :: Notifications and Alerts, defect)

45 Branch
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: dw-dev, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160303134406 Steps to reproduce: I am porting one of my add-ons (Navigate Up) to use the new WebExtensions interface. When testing Navigate Up, I used chrome.notifications.create to display some debug messages. Actual results: The notification popups are normally displayed in the bottom right corner of the screen, but if there are a large number of notifications they overflow and are positioned just above the top of the screen and are not visible. When this happens, if Firefox is restarted, any new notification popups are positioned just above the top of the screen and are not visible. Expected results: All notification popups should be positioned on the visible screen, even if they are stacked on top of each other. None of the notification popups should be positioned off-screen.
Retriage to Alerts and Notfications, if the component is wrong.
Component: Untriaged → WebExtensions
Product: Firefox → Toolkit
Component: WebExtensions → Notifications and Alerts
Tested on: Firefox 22 - 52.0a1 Windows 7/8 Ubuntu 16.04 Steps to reproduce: Confirmed on: Windows 7/8 (does not work) Not confirmed on: Ubuntu 16.04 (works) 1) Open Scratchpad 2) Menu: "Environment-Browser" 3) Insert the code: // 1, 2 var type = 1; var repeat = 4; var timeout = 500; var count = 0; function log(count) { window.setTimeout(function () { if (count == repeat) { // Position the window at the end of all alerts. var windows = Services.wm.getEnumerator("alert:alert"); while (windows.hasMoreElements()) { var alertWindow = windows.getNext(); if (alertWindow != window) { console.log("Position the window at the end of all alerts. - alertWindow.screenY: " + alertWindow.screenY); } } } }, 1000); } if (type == 1) { var i = 1; var interval = window.setInterval(function () { new Notification("Hi! " + i.toString() + " " + (new Date).getTime(), {}); count++; log(count); if (i++ == repeat) { window.clearInterval(interval); } }, timeout); } else if (type == 2) { for (var i = 0; i < repeat; i++) { window.setTimeout(function () { new Notification("Hi! " + i.toString() + " " + (new Date).getTime(), {}); count++; log(count); }, timeout); } } 4) Run 5) The result: (see https://hg.mozilla.org/mozilla-central/file/7c576fe3279d/toolkit/components/alerts/resources/content/alert.js#l220) Windows 7/8: [type == 1] It shows 4(repeat) notifications (from bottom to top). Also after rerunning. In Browser Console: Position the window at the end of all alerts. - alertWindow.screenY: 805 Position the window at the end of all alerts. - alertWindow.screenY: 760 Position the window at the end of all alerts. - alertWindow.screenY: 715 Position the window at the end of all alerts. - alertWindow.screenY: 670 [type == 2] Nothing is displayed. Just a shadow of notification (for Firefox 45+) - in the top right of the screen. It works properly (only) with repeat=1. In Browser Console: Position the window at the end of all alerts. - alertWindow.screenY: -45 Position the window at the end of all alerts. - alertWindow.screenY: -90 Position the window at the end of all alerts. - alertWindow.screenY: -135 Position the window at the end of all alerts. - alertWindow.screenY: -180 Ubuntu 16.04: [type == 1,2] It shows 4(repeat) notifications (from top to bottom). Also after rerunning. Position the window at the end of all alerts. - alertWindow.screenY: 34 Position the window at the end of all alerts. - alertWindow.screenY: 78 Position the window at the end of all alerts. - alertWindow.screenY: 122 Position the window at the end of all alerts. - alertWindow.screenY: 166
This seems to happen if notifications are rapid-fired. Race condition?
> This seems to happen if notifications are rapid-fired. Race condition? Yes and no. This limit: "timeout=10000" - has no effect (if "type == 2").
(In reply to janekptacijarabaci from comment #8) > Yes and no. This limit: "timeout=10000" - has no effect (if "type == 2"). But the problem is that you're firing all of them close together. It doesn't matter how long the initial delay is; the timeouts would all fire pretty much in the same instant.
It's about what you mean: for (var i = 0; i < repeat; i++) { // Delay var start = (new Date()).getTime(); for (var j = 0; j < 1e7; j++) { if (((new Date()).getTime() - start) > 2000){ break; } } console.log("I'm here at this time: " + (new Date)); // After 2 seconds window.setTimeout(function () { new Notification("Hi! " + i.toString() + " " + (new Date).getTime(), {}); count++; log(count); }, timeout); } Still no effect.
You really shouldn't be using busy wait loops in JavaScript (or anywhere, really...). Something like this would be more appropriate: const COUNT = 10; const INTERVAL = 500; for (let i = 0; i < COUNT; i++) { setTimeout(() => { new Notification(`Notification ${i} ${Date()}`, {}); }, i * INTERVAL); }
> You really shouldn't be using busy wait loops in JavaScript (or anywhere, really...). Thank you. But this is just a sample. In fact, it is necessary to use differently (notifications will not be completely identical - and they come in succession).
Anything with 2-second busy wait loops is not a good example. That's a pathological state for a browser, where you should expect things to behave poorly.
> ...is not a good example. Yes, it isn't. Maybe the example wasn't the best, but the original problem still persists (Notification positions are wrong, in normal use - without identifying active notifications). And as noted by others, some websites don't work properly.
(In reply to janekptacijarabaci from comment #5) Tested on: Firefox 49.0 Windows 10 Ubuntu 16.04 Seems to be windows-only bug, I got exactly the same result as you for each platform.
> Seems to be windows-only bug, I got exactly the same result as you for each platform. Yes, it is possible. I guess it's some setting (on Linux) that differs.
Depends on: 1007344

Hello, can you confirm this was fixed by bug 1007344 in Nightly?

Flags: needinfo?(dw-dev)

I have not seen this problem recently and so I can confirm it has been fixed.

Flags: needinfo?(dw-dev)
Severity: normal → S3
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.