1088884 - In Firefox Hello's "Sad" feedback form, the user's text input is cleared (& unrecoverable) if they click any of the radio buttons

Status: RESOLVED DUPLICATE of bug 1079227

(Hello (Loop) :: Client, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Complete a call with Firefox Hello.

 2. Click the sad face.

 3. See the "What went wrong?" textfield -- type something in there.
   --> This selects the "Other" radio button.

 4. Now, click any of the radio buttons above that field.

ACTUAL RESULTS: Your text input is cleared. It's cleared even if you click "Other" (the radio button that it's associated with).

EXPECTED RESULTS:
 - Nothing should change if you click the (already-selected) "Other" button
 - If you click a different button, perhaps the field should be *disabled* or *hidden* (but not cleared). It should be restored (with the text you entered) if you then click "Other" again.


The current state makes for a really bad user experience. When the user hits this UI, they've presumably just had a negative experience, and they're trying to help us by describing it. If we just inadvertantly delete their carefully-crafted explanation, it's kind of a slap in the face.

I'm running 36.0a1 (2014-10-23)

Comment 1

[u279076]

Paul, can you please confirm this behaviour and check if it affects Aurora/Beta as well?

Comment 2

[Daniel Holbert [:dholbert]]

I just tested & confirmed that this affects Aurora (35), FWIW.

I couldn't test Beta because I couldn't find a "Hello" icon there (it's not present in the customize view, as far as I can tell).

Comment 3

[u279076]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> I couldn't test Beta because I couldn't find a "Hello" icon there (it's not
> present in the customize view, as far as I can tell).

Please set loop.throttled=false in about:config and try again.

Comment 4

[Daniel Holbert [:dholbert]]

Thanks. Affects Beta as well, with that pref tweak.
Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0

(The content looks the same in all three -- I'm guessing this content might be hosted on a web server, rather than being bundled in Firefox. [in which case maybe this bug belongs in the "server" component])

Comment 5

[Daniel Holbert [:dholbert]]

Yeah, it looks like this functionality comes from a combination of these scripts (both of which include stuff about "feedback"), and perhaps other scripts as well:
  https://hello.firefox.com/shared/js/feedbackApiClient.js
  https://hello.firefox.com/js/webapp.js

Moving to "Server".

Comment 6

[u279076]

(In reply to Daniel Holbert [:dholbert] from comment #5)
> Moving to "Server".

QA Contact for Server is Richard.

Comment 7

[Mark Banner (:standard8)]

We use client for the standalone ui as well as the desktop as they have shared code and the main server is separate and manages the connections between clients.

Comment 8

[Romain Testard [:RT]]

Bug 1077257 will fix this.
I added a comment on bug 1077257 to make sure that the text does not get cleared as the user selects a different option.

Comment 9

[u279076]

Clearing status flags since this is being taken care of in bug 1077257.

Comment 10

[Daniel Holbert [:dholbert]]

Per bug 1077257 comment 29, the issue described here is actually covered in bug 1079227, which is now fixed (hooray!).

Adjusting dupe-target to the correct bug.