794686 - Text not rendered in <input> until switching tabs or otherwise re-rendering the window

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

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

This appears to have re-regressed. Not sure exactly when as I went about a week and a half without updating my build. Same steps as before. Sure would have been nice if we'd gotten a working test the last time around... :(

Comment 1

[Timothy Nikkel (:tnikkel)]

Perhaps this is the same as bug 793998.

Comment 2

[Alice0775 White]

Attachment: reduced html

Comment 3

[Alice0775 White]

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/f7c89de3ab43
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120915201302
Bad:
http://hg.mozilla.org/mozilla-central/rev/b3f462d96fb5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120916161603
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f7c89de3ab43&tochange=b3f462d96fb5

Regression window(m-c)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/33087122ace7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120916022601
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6ee831a85d12
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120916033402
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33087122ace7&tochange=6ee831a85d12

Suspected:Bug 788044

Comment 4

[Chris Lord [:cwiiis]]

Excellent test-case, will try to fix this and add a reftest to prevent it being broken again (though I expect DLBI will make this particular error extremely unlikely to manifest).

Comment 5

[Chris Lord [:cwiiis]]

Seems this is a case of a container layer being created, then lost when retaining layers on the next draw (in this case, the container layer for the transform). I thought I fixed a very similar issue before, but can't quite remember how or why, so going over this again...

Comment 6

[Chris Lord [:cwiiis]]

Somewhat interestingly, if I force the transform item to always be active, updates still don't work, despite going to both the transform and fixed position item container layers...

Comment 7

[Chris Lord [:cwiiis]]

So it seems the invalidation is actually reaching the right layer (at least with forced active transforms). Perhaps the coordinates are wrong?

Comment 8

[Chris Lord [:cwiiis]]

Starting to think this may actually be to do with native widget drawing (which would make this a separate issue to bug 787471) - the invalidations look correct and I notice the red outline around the text entry seems to update correctly, but the area that intersects with the native widget is not updated (including where it intersects with the red highlight...)

Quite odd behaviour... Will confirm by adding style to the entry.

Comment 9

[Chris Lord [:cwiiis]]

Ok, unfortunately nothing to do with that.

Comment 10

[Chris Lord [:cwiiis]]

Of course, I hadn't considered that the invalidation is a region, not a rect - the odd invalidation of the red outline is just indicative of the offset being wrong. Just need to find out why the offset is wrong.

Comment 11

[Chris Lord [:cwiiis]]

Just to confirm, it does indeed expect things to be relative to the origin of the transformed frame. Manually offsetting it fixes the issue.

Comment 12

[Chris Lord [:cwiiis]]

erk, but not forcing active on the transform still exhibits the problem, so it appears there are two distinct problems here? Or perhaps the root cause of the incorrect offset will fix both...(?)

Comment 13

[Chris Lord [:cwiiis]]

False alarm, it's still the offset, I just set it in a place that only affected this page when the transform is active :)

Comment 14

[Chris Lord [:cwiiis]]

Extra note - this has nothing to do with position:fixed - forcing transforms to be active and removing the position:fixed declaration from the attached test-case still exhibits the error.

Comment 15

[Chris Lord [:cwiiis]]

I wish I'd noticed that bug 788044 was suspected before, this is very likely the cause. Hopefully be able to work out a fix today.

Comment 16

[Chris Lord [:cwiiis]]

Just to note that simply setting a transform is enough to trigger this bug under many circumstances, there's no need for the nested divs, position:fixed, etc. This is a regression caused by bug 788044.

I've spoken to Matt Woodrow about it - if DLBI sticks, we should back this out of Aurora, otherwise we'll devise and check in a fix.

Comment 17

[Chris Lord [:cwiiis]]

Attachment: Fix invalidations on transforms

try: https://tbpl.mozilla.org/?tree=Try&rev=6a5e63ccbf3c

I'm not sure if this is entirely correct, but it feels correct given the changes from bug 788044 and it fixes the problem without obviously causing others.

This is for Aurora only, this problem is fixed by DLBI.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Confirmed that this is fixed on trunk by DLBI. Leaving open for the Aurora patch.

Comment 19

[Chris Lord [:cwiiis]]

Comment on attachment 665930 [details] [diff] [review]
Fix invalidations on transforms

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 788044 caused this regression.
User impact if declined: Transformed elements will often not update.
Testing completed (on m-c, etc.): Local testing looked good and try runs are green.
Risk to taking this patch (and alternatives if risky): Medium risk. This hasn't received as much testing as I'd like, but seems ok. It can't be landed on central because it conflicts with DLBI. Backing out bug 788044 is non-trivial, there are conflicts, so I'm not sure what the better option is. This is certainly the least work of the two options, so perhaps ought to be tried first.
String or UUID changes made by this patch: None

Comment 20

[Alex Keybl [:akeybl]]

(In reply to Chris Lord [:cwiiis] from comment #19)
> Comment on attachment 665930 [details] [diff] [review]
> Fix invalidations on transforms
> 
> [Approval Request Comment]
> Bug caused by (feature/regressing bug #): Bug 788044 caused this regression.
> User impact if declined: Transformed elements will often not update.

I'm probably being daft, but didn't bug 788044 land in FF18 and not 17?

Comment 21

[Chris Lord [:cwiiis]]

(In reply to Alex Keybl [:akeybl] from comment #20)
> (In reply to Chris Lord [:cwiiis] from comment #19)
> > Comment on attachment 665930 [details] [diff] [review]
> > Fix invalidations on transforms
> > 
> > [Approval Request Comment]
> > Bug caused by (feature/regressing bug #): Bug 788044 caused this regression.
> > User impact if declined: Transformed elements will often not update.
> 
> I'm probably being daft, but didn't bug 788044 land in FF18 and not 17?

You're right... Does this *actually* effect 17? Adding qawanted flag to confirm.

Comment 22

[Federico Padua [:fedepad]]

I checked for this problem on 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121004042009

I used the reduced html to test. The problem doesn't show up, it appears to work fine.

Comment 23

[Chris Lord [:cwiiis]]

Marking this as fixed (by DLBI) and marking Aurora as unaffected.

Comment 24

[Chris Lord [:cwiiis]]

Comment on attachment 665930 [details] [diff] [review]
Fix invalidations on transforms

Removing aurora approval request, unnecessary.

Comment 25

[Ada [:adalucinet]]

Verified as fixed on Mac OS, Ubuntu and Windows 7 with Firefox beta 6.

Comment 26

[u279076]

(In reply to Alexandra Lucinet [QA] from comment #25)
> Verified as fixed on Mac OS, Ubuntu and Windows 7 with Firefox beta 6.

Thanks Alexandra. Setting the status flag to verified as well.

Comment 27

[u279076]

Ryan, does this have or need a testcase in-testsuite?

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Would be nice given that this was filed as a regression of a prior fix. Chris, is there a way to test this?

Comment 29

[Chris Lord [:cwiiis]]

(In reply to Ryan VanderMeulen from comment #28)
> Would be nice given that this was filed as a regression of a prior fix.
> Chris, is there a way to test this?

The attached HTML test case, if text typed into the text box appears, it works.

This bug was caused by bug 788044, but was fixed by DLBI - given they both landed in the same version, this bug has not been in any release, as far as I'm aware.