Opened 9 years ago

Closed 9 years ago

#5007 closed Bug (fixed)

Web client attempts to post notifications without permission, causing transfers not to update

Reported by: SG Owned by: livings124
Priority: Normal Milestone: 2.70
Component: Web Client Version: 2.61
Severity: Normal Keywords:
Cc:

Description

Starting in 2.61 of the Web Client, when a torrent finishes downloading it does not update it's status as completed and change to seeding or changes it's color from blue to green until a reload is done in the browser. This did not happen in previous versions.

I'm using the 'released builds' from https://launchpad.net/~transmissionbt/+archive/ppa for Ubuntu 12.04.

Change History (10)

comment:1 Changed 9 years ago by livings124

This is working for me with 2.61. What browser are you using? Are you waiting a bit of time for it to change by itself?

Last edited 9 years ago by livings124 (previous) (diff)

comment:2 Changed 9 years ago by zp_

This also happens to me, I'm running 2.61 on Arch Linux, I have set the refresh time to 1 second down from 5, and running the latest version of Chrome.

edit: Also if you add a torrent after one finishes, it wont display the new torrent until you do a manual refresh of the page.

Tried switching back to the 2.52 webui, and it refreshes the torrent info correctly.

Last edited 9 years ago by zp_ (previous) (diff)

comment:3 Changed 9 years ago by SG

I did some more testing, it seems to only affect Chrome and Safari while Firefox works (all latest versions: Safari 6.0, Chrome 22, FF 14.0.1).

This error shows up in the Chrome console after a download is complete:

18 Uncaught Error: SECURITY_ERR: DOM Exception 18 notifications.js:18

Safari gives this error:

3 notifications.js:18SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent. notifications.js:18

Looking at line 18 of notifications.js shows this line :

notification = window.webkitNotifications.createNotification('style/transmission/images/logo.png', title, content);

Last edited 9 years ago by SG (previous) (diff)

comment:4 Changed 9 years ago by SG

looked into it a bit more and it's all part of the new webkitNotifications and it seems the notifications.js in the Web Client is blindly trying to fire off some notifications without getting permission. It isn't ever asking permission for access. Whitelisting all sites in Chrome preferences shows the notification does go through when completed and properly changes the status to 'seeding' and the colour to green.

Last edited 9 years ago by SG (previous) (diff)

comment:5 Changed 9 years ago by livings124

  • Milestone changed from None Set to 2.70
  • Owner set to livings124
  • Status changed from new to assigned

comment:6 Changed 9 years ago by livings124

  • Resolution set to fixed
  • Status changed from assigned to closed
  • Summary changed from Web Client: completed downloads doesn't update status to Web client attempts to post notifications without permission, causing transfers not to update

r13422 should fix this.

comment:7 Changed 9 years ago by SG

just tested that version of notifications.js and while the status does update, it doesn't seem to address in prompting for permission to display notifications. without permission the notification will never work.

comment:8 Changed 9 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:9 Changed 9 years ago by SG

sorry my mistake, that previous fix was it. i didn't notice that the gear/settings button at the bottom left corner had an option for enabling notifications, i somewhat assumed it would prompt based on the previous way the code was trying to enable it.

to recap, the changed code will now update the status for a browser that supports notifications but has it disabled and will fire the notification also if the browser supports it and the user clicked the gear to enable.

thanks a lot and sorry for that previous comment causing you to re-open the ticket.

comment:10 Changed 9 years ago by livings124

  • Resolution set to fixed
  • Status changed from reopened to closed

:-)

Note: See TracTickets for help on using tickets.