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

When a call URL is deleted/blocked, use the proper session

VERIFIED FIXED in Firefox 34

Status

Hello (Loop)
Client
--
major
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: MattN, Assigned: standard8)

Tracking

unspecified
mozilla36
Points:
1
Bug Flags:
firefox-backlog +
in-qa-testsuite -
in-testsuite +
in-moztrap -
qe-verify +

Firefox Tracking Flags

(firefox34+ verified, firefox35 verified, firefox36 verified)

Details

(URL)

User Story

As a signed-in FF browser user, I can decline and block a call from link clickers using a call URL.

Attachments

(1 attachment)

+++ This bug was initially created as a clone of Bug #1065155 +++

Bug 1065155 was supposed to cover deleting (aka. blocking) call URLs but it didn't do so: https://mxr.mozilla.org/mozilla-central/source/browser/components/loop/content/js/client.js?rev=e2f7534c7687#185

I haven't manually testing but my understanding is that a user currently can't block a call from a call URL that was generated while logged in to Loop.
Flags: qe-verify+
Flags: firefox-backlog+
Matt -- Will this bug effectively go away when we move to Rooms?
Flags: needinfo?(MattN+bmo)
I think so. It may be a good idea to fix it for the earlier releases to deal with abuse.
Flags: needinfo?(MattN+bmo)
Mark, what would be the best way to the session which created the call URL we're about to delete?
Flags: needinfo?(standard8)
What would be the best way to find out the session which created the call URL we're about to delete?

e.g. Call comes in to https://hello.firefox.com/#call/04-92QkSxfoo and I click "decline and block". Do we currently keep track of which of the two call requests returned the call after the push?
(Assignee)

Comment 5

3 years ago
Created attachment 8517373 [details] [diff] [review]
When a Loop call URL is deleted/blocked, use the proper session.

I took a look, and the patch was easy, so I just went ahead and fixed it.

In LoopCalls, we already keep track of the sessionType in the _getCalls/_processCalls functions. The sessionType is passed to the window (via callData), and stored in the conversation model.

The simple fix is then just to extract the information, and use it in the delete function.
Attachment #8517373 - Flags: review?(MattN+bmo)
(Assignee)

Comment 6

3 years ago
Oh forgot to say, I tested a few scenarios such as:

- Whilst logged out: get a call url & start incoming call from url & block it.
- Whilst logged in: get a call url & start incoming call from url & block it.
- Whilst logged out: generate a call url, then log in, start incoming call from url & block it.

They all worked fine.
Assignee: nobody → standard8
backlog: Fx36? → Fx34?
Iteration: --- → 36.2
Points: --- → 1
Flags: needinfo?(standard8)
(Assignee)

Comment 7

3 years ago
I just checked beta, and the sessionType should be available in the right places there as well. So there shouldn't be a need for a different patch on aurora/beta.
(Assignee)

Comment 8

3 years ago
Comment on attachment 8517373 [details] [diff] [review]
When a Loop call URL is deleted/blocked, use the proper session.

Switching to Mike as he's around
Attachment #8517373 - Flags: review?(MattN+bmo) → review?(mdeboer)
Comment on attachment 8517373 [details] [diff] [review]
When a Loop call URL is deleted/blocked, use the proper session.

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

LGTM
Attachment #8517373 - Flags: review?(mdeboer) → review+
(Assignee)

Comment 10

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/7902458c79ec
Target Milestone: --- → mozilla36
Comment on attachment 8517373 [details] [diff] [review]
When a Loop call URL is deleted/blocked, use the proper session.

Approval Request Comment
[Feature/regressing bug #]: Blocking a call (link-clicked call) when the user is logged in

[User impact if declined]: If declined, there is no way for a user to block a call if they are logged in aside from logging out of the system or changing profiles.

[Describe test coverage new/current, TBPL]: tbpl, manual testing

[Risks and why]: No risk outside of Loop, minimal risk to Loop.  Without this, a logged-in user can't block a call for link they shared with someone.  It's potentially an abuse/harrassment issue.

[String/UUID change made/needed]: No strings
Attachment #8517373 - Flags: approval-mozilla-beta?
Attachment #8517373 - Flags: approval-mozilla-aurora?
[Tracking Requested - why for this release]: See Comment 11
backlog: Fx34? → Fx34+
status-firefox34: --- → affected
status-firefox35: --- → affected
status-firefox36: --- → affected
tracking-firefox34: --- → ?
https://hg.mozilla.org/mozilla-central/rev/7902458c79ec
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
tracking-firefox34: ? → +
status-firefox36: affected → fixed
Flags: in-qa-testsuite-
Flags: in-moztrap-
Checked on m-c tbpl builds, in a bunch of variations.  Works as it should.  Try runs for Aurora and Beta running.
status-firefox36: fixed → verified
Tested on Aurora Try build, no problems
https://hg.mozilla.org/releases/mozilla-aurora/rev/7b1cbdeed5d8
status-firefox35: affected → fixed
Tested on Beta Try build, no problems
https://hg.mozilla.org/releases/mozilla-beta/rev/caa27159afeb

Aurora and beta landing per discussion with lmandel
status-firefox34: affected → fixed
Comment on attachment 8517373 [details] [diff] [review]
When a Loop call URL is deleted/blocked, use the proper session.

Previously provided approval via irc. Marking the bug with approval for record keeping.
Attachment #8517373 - Flags: approval-mozilla-beta?
Attachment #8517373 - Flags: approval-mozilla-beta+
Attachment #8517373 - Flags: approval-mozilla-aurora?
Attachment #8517373 - Flags: approval-mozilla-aurora+
Verified FF 34b7, 35.0a2 (2014-11-10) Win 7
Status: RESOLVED → VERIFIED
status-firefox34: fixed → verified
status-firefox35: fixed → verified
You need to log in before you can comment on or make changes to this bug.