1137031 - textarea for editing comments for amazon wishlist items is invisible

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Nathan Froyd [:froydnj]]

[Tracking Requested - why for this release]:
Requesting tracking for possible regression on Amazon.com

STR:

1. Have an Amazon wishlist with items in it.
2. Choose an item and click "Edit comment, quantity, and priority"
3. A popup will appear, but with no textarea to edit the comment.

This works in 36 for me, but not in nightly--tried 36 on Windows, nightly on Linux and Windows.  e10s does not seem to make a difference.  The weird thing is that there is a <textarea> in the DOM, according to the devtools inspector, but one can't click on the textarea.  (And bringing up the devtools inspector can make the textarea visible and editable sometimes.)

I'm assuming this is DOM, but am equally willing to believe that it's a problem in the frontend.

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 39 since this is a popular site.  
We should check to see if 37 and 38 are affected too.

Comment 2

[Alice0775 White]

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f1e0ee57dee0&tochange=60d2f893feb9

Suspect: Bug 1125391


STR:

1. Have an Amazon wishlist with items in it.
2. Choose an item and click "Edit comment, quantity, and priority"
3. A popup will appear, but with no textarea to edit the comment.

You may need the following extra steps
4. Close the popup
5. Choose an item again and click "Edit comment, quantity, and priority"

In any case, the textbox appears if you resized browser window.

I can reproduce on Nightly39.0a1 and Aurora38.0a2.
But I cannot reproduce on Firefox37.0b1.

Comment 3

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 4

[Cameron McCormack (:heycam)]

Alice, can you see if applying the patch in bug 1136010 solves the problem?

Comment 5

[Alice0775 White]

(In reply to Cameron McCormack (:heycam) from comment #4)
> Alice, can you see if applying the patch in bug 1136010 solves the problem?

Via local build
Build from m-i cset c40a8aba7b4d : 
I can reproduce the problem.

Build from m-i cset c40a8aba7b4d + attachment 8569091 [details] [diff] [review] in bug 1136010:
I can still reproduce the problem. 
So, the patch in bug 1136010 seems do NOT fix this problem.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Alice0775, thank you!

Comment 7

[Cameron McCormack (:heycam)]

There is a |input, select, textarea { transition: all 100ms; }| rule in the document and we end up with visibility:hidden set by an animation rule.  If I force visibility to be not animatable in nsCSSPropList.h, the textarea and inputs appear as expected.

Comment 8

[Cameron McCormack (:heycam)]

Attachment: patch

This patch fixes the problem, though I'll hold off on requesting review until I understand why it fixes it (and create a reduced test).

Comment 9

[Cameron McCormack (:heycam)]

I think the answer is probably something like: it's not safe to return eRestyleResult_Stop when TryStartTransitions replaced newContext with one that has the "after-change style", because the subsequent restyle then might not notice the same property value differences when consider whether to start/cancel an transition.

Comment 10

[Cameron McCormack (:heycam)]

(In reply to Cameron McCormack (:heycam) from comment #9)
> I think the answer is probably something like: it's not safe to return
> eRestyleResult_Stop when TryStartTransitions replaced newContext with one
> that has the "after-change style", because the subsequent restyle then might
> not notice the same property value differences when consider whether to
> start/cancel an transition.

And one specific reason why we should not return eRestyleResult_Stop here is that the rule node of the "after-change style" object will be different.  So we have a sufficiently different new style context, and we shouldn't leave the old one on the frame.

Comment 11

[Cameron McCormack (:heycam)]

I spent half of today trying to generate a reduced test case but failed, so I'm giving up on that for now.

Comment 12

[Cameron McCormack (:heycam)]

I think the important thing, for the Amazon page, is that it is not correct to leave the frame's old style context there when nsTransitionManager replaced our new context with one without animations, as that can cause the subsequent restyle to be incorrect.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8571791 [details] [diff] [review]
patch

r=dbaron, though it needs a useful commit message saying what's changing.

Comment 14

[Cameron McCormack (:heycam)]

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=c5a6c94eda71

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c5a6c94eda71

Comment 16

[Cameron McCormack (:heycam)]

Comment on attachment 8571791 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: bug 1125391
[User impact if declined]: inability to use certain features on Amazon (problems with restyling and transitions)
[Describe test coverage new/current, TreeHerder]: tested manually, landed on central (inbound here: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=c5a6c94eda71)
[Risks and why]: low, we are just adding a condition when we don't perform a particular optimisation
[String/UUID change made/needed]: N/A

Comment 17

[Cameron McCormack (:heycam)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/bcfac4ff0a06

Comment 18

[pgtoennies]

I am still seeing this issue with Firefox 45. Often when I try to add a comment to an item on my amazon wishlist, a popup window will appear which does not have any space to enter a comment. I have to press a cancel button. Afterwards, when I select to add a comment for the item, the proper input box appears.