Closed
Bug 1160049
Opened 10 years ago
Closed 9 years ago
[Messages] Attach menu should not dismiss when user cancel the replace attachment request
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Tracking
(blocking-b2g:2.5+)
RESOLVED
WORKSFORME
blocking-b2g | 2.5+ |
People
(Reporter: steveck, Assigned: steveck)
Details
(Keywords: regression)
Attachments
(1 file)
After Bug #1156711 landed, the attachment menu will reuse the current shared option menu. Menu will be dismissed after clicking the option on the menu, but UX would prefer to keep it on top if user cancel the replace request. we might need to invent an option for enable menu closing manually in option menu.
Comment 1•10 years ago
|
||
[Blocking Requested - why for this release]:
Good catch; let's nominate it to keep this bug visible as it is a regression.
blocking-b2g: --- → 3.0?
Keywords: regression
Comms triage: Regression
blocking-b2g: 3.0? → 3.0+
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → schung
Comment 3•9 years ago
|
||
Assignee | ||
Comment 4•9 years ago
|
||
Comment on attachment 8637823 [details]
[gaia] steveck-chung:new-message-attachment-menu > mozilla-b2g:master
Hi Oleg, it's a small follow up for the attachment context menu regression. I think we only need it for replace case so I didn't move this part in generic error handling.
Attachment #8637823 -
Flags: review?(azasypkin)
Comment 5•9 years ago
|
||
Comment on attachment 8637823 [details]
[gaia] steveck-chung:new-message-attachment-menu > mozilla-b2g:master
Hey Steve,
Sorry for the delay, I've left alternative proposition at GitHub that based on modified OptionMenu instead.
Please, tell me what you think!
Attachment #8637823 -
Flags: review?(azasypkin)
Assignee | ||
Comment 6•9 years ago
|
||
Comment on attachment 8637823 [details]
[gaia] steveck-chung:new-message-attachment-menu > mozilla-b2g:master
Hi Oleg, I agree that the original solution is hacky because the option menu should be updated with part of gaia-component in the future. So I didn't want to change the shared option menu at first. But adding this feature in option menu shouldn't cause regression anyway. I add the hideOnAction to item and see if you agree with this idea, thanks!
Attachment #8637823 -
Flags: review?(azasypkin)
Assignee | ||
Comment 7•9 years ago
|
||
Patch updated with name changed to "hideMenuManually", wdyt?
Flags: needinfo?(azasypkin)
Comment 8•9 years ago
|
||
Comment on attachment 8637823 [details]
[gaia] steveck-chung:new-message-attachment-menu > mozilla-b2g:master
Sorry for a delay! Looks good to me now, just one question at GitHub,
Thanks!
Flags: needinfo?(azasypkin)
Attachment #8637823 -
Flags: review?(azasypkin) → review+
Comment 9•9 years ago
|
||
After discussion with Steve, I have different view than the previous UX owner. I would prefer not to go back to show the option menu if user cancel the replace request, that is it will dismiss all option menu whenever user cancel the replace request. This can not only make it consistent with different apps across the OS, but also do give user the ability to actually "cancel". Besides, user can easily to replace the attachment by bringing out the option menu again. Does that make sense? Let me know if any questions, thanks.
Assignee | ||
Comment 10•9 years ago
|
||
Close as worksforme per comment 9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•