873937 - [Everything.me][Gmail]Recipient address disappears from "TO" field of compose mail screen and reappears after short time

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Leo]

STR:
1. Open Gmail application from Everything.me -> Social.
2. Login and navigate to "compose mail" screen
3. Enter address manually to the "To" field of the compose screen

Actual:
1. When the address fills the "To" field box, the address disappears and reappears when new character is entered.

Expected:
1. The address in the "To" field should be displayed constantly.

Reproducibility: 100%
Gaia-branch: gaia/master
Gaia revision: af15e30051af05a150d85fbe29e5fa9b6bbc2570

Comment 1

[Leo]

Hi jason,

Please let know the scope of fixing this issue also how issues from such 3rd party applications are handled.

Comment 2

[Jason Smith [:jsmith]]

This doesn't reproduce on 1.01, so it's likely a gecko bug then.

Comment 3

[Dylan Oliver [:doliver]]

Leo QE2 bug -- nominating for 1.1

Comment 4

[Tracy Walker [:tracy]]

I am able to reproduce this on 1.1 with Ikura device.

Once the To: field is overflowed each character entry thereafter causes the entire field to go blank for ~4 seconds, then all the entered text reappears.

Comment 5

[Wayne Chang [:wchang]]

Jason, do you know which 1.01 build you tested? 
I just tested on a buri with build 20130518070208 and can see this bug.

Hi Matt, Is this something you can take a look at?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Wayne Chang [:wchang] from comment #5)
> Jason, do you know which 1.01 build you tested? 
> I just tested on a buri with build 20130518070208 and can see this bug.

It was an Inari 1.01 build on 5/20.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to Wayne Chang [:wchang] from comment #5)
> > Jason, do you know which 1.01 build you tested? 
> > I just tested on a buri with build 20130518070208 and can see this bug.
> 
> It was an Inari 1.01 build on 5/20.

Oh I should also note - I didn't see this bug on 1.01 with my build with this STR, but I did see this exact bug using the auth dialog for evernote in the notes app on 1.01. So yeah, you are right.

Comment 8

[leo.bugzilla.gecko]

This issue might be a regression of 1.1

Comment 9

[Matt Woodrow (:mattwoodrow)]

I don't have an Inari/Buri device to test this. Would it be possible to bisect between 1.0.1 and 1.1 and find when this regressed?

Comment 10

[Angela Hubenya]

Regression window results for v1 on this issue: 
2013-01-15-07-02-01 PASS
2013-01-15-23-02-01 PASS
2013-01-16-07-02-04 FAIL
2013-01-17-07-02-01 FAIL

Comment 11

[Jason Smith [:jsmith]]

http://hg.mozilla.org/releases/mozilla-b2g18/pushloghtml?startdate=2013-01-15&enddate=2013-01-16

Comment 12

[Jason Smith [:jsmith]]

I've got a strong hunch bug 826829 broke this.

Sotaro - What do you think?

Comment 13

[Sotaro Ikeda [:sotaro]]

(In reply to Jason Smith [:jsmith] from comment #12)
> I've got a strong hunch bug 826829 broke this.
> 
> Sotaro - What do you think?

bug 826829 changes how ImageContainerChild works. Though, iirc, ImageContainerChild is used only for video rendering.

Comment 14

[Sotaro Ikeda [:sotaro]]

:nical, is ImageContainerChild used only for video frame rendering?

Comment 15

[Nicolas Silva [:nical]]

(In reply to Sotaro Ikeda [:sotaro] from comment #14)
> :nical, is ImageContainerChild used only for video frame rendering?

At the moment it is only used for video. In the future we will use it for more types of async content (like animated images, probably webgl workers, etc.)

Comment 16

[Sotaro Ikeda [:sotaro]]

(In reply to Jason Smith [:jsmith] from comment #11)
> http://hg.mozilla.org/releases/mozilla-b2g18/pushloghtml?startdate=2013-01-
> 15&enddate=2013-01-16

I reverted following 3 on v1.1 buri. But the problem still happend.

- Sotaro Ikeda — Bug 826829 - Change ImageContainerChild::DispatchSetIdle() to synchronous SetIdle(). r=kanru, a=tef+
- Sotaro Ikeda — Bug 826829 - Change PImageContainer::Flush() to synchronous to prevent abort. r=kanru, a=tef+
- Kyle Huey — Bug 824658 - Avoid infinite decode loops of images by switching some GetFrame calls to GetFrameNoDecode. r=joe, a=overholt

Comment 17

[Sotaro Ikeda [:sotaro]]

Attachment: a screenshot of the problem happened with layers borders

I checked the bug on master. master implements new "Draw layers borders" debugging capability. By using this, it become clear that only during the problem happening, layer appear on the input area.

Comment 18

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> Created attachment 759956 [details]

From the screen shot, it becomes clear that the problem is around layout and display list. But there is no such change in "Changes pushed after 2013-01-15 00:00:00, before 2013-01-16 00:00:00".

Comment 19

[Sotaro Ikeda [:sotaro]]

I feel that for some reasons "Changes pushed after 2013-01-15 00:00:00, before 2013-01-16 00:00:00" does not include the actual defect.

Comment 20

[Sotaro Ikeda [:sotaro]]

I unassign myself. It becomes clear that my change does not related to the bug. And it is better to be investigated by a layout specialist.

Comment 21

[Sotaro Ikeda [:sotaro]]

I am going to investigate about the bug more.

Comment 22

[Sotaro Ikeda [:sotaro]]

I confirmed the problem happens also on "UI Tests -> text inputmode tests". On text input area that have low height.

Comment 23

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #18)
> (In reply to Sotaro Ikeda [:sotaro] from comment #17)
> > Created attachment 759956 [details]
> 
> From the screen shot, it becomes clear that the problem is around layout and
> display list. But there is no such change in "Changes pushed after
> 2013-01-15 00:00:00, before 2013-01-16 00:00:00".

It is normal that a layer appear over input area for some seconds when input filed overlows. I confirmed that it happened also other input area.

Comment 24

[Sotaro Ikeda [:sotaro]]

I temporarily disable a Gralloc buffer and use shmem for Layer buffer by uisng a way in Bug 871624. In shmem drawing, the problem did not happen.

Comment 25

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #24)
> I temporarily disable a Gralloc buffer and use shmem for Layer buffer by
> uisng a way in Bug 871624. In shmem drawing, the problem did not happen.

I feel that it is very similar to Bug 792966.

Comment 26

[Sotaro Ikeda [:sotaro]]

Attachment: patch - do not use gralloc buffer when texture is small

Confirmed the patch works on mster buri.

Comment 27

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #26)
> Created attachment 760214 [details] [diff] [review]
> patch - do not use gralloc buffer when texture is small
> 
> Confirmed the patch works on mster buri.

This way does not work for b2g18. master was polished by layer refactoring. It seems that it is affected by it.

Comment 28

[Sotaro Ikeda [:sotaro]]

Attachment: patch for b2g18 - do not use gralloc buffer when texture is small

Confirmed that the patch fixes the problem on v1.1 buri. I am not sure whether this fix is correct.

Comment 29

[Sotaro Ikeda [:sotaro]]

Diego, do you know whether qcom's gpu have a restriction to minimum texture size?

Comment 30

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 760224 [details] [diff] [review]
patch for b2g18 - do not use gralloc buffer when texture is small

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

::: gfx/gl/GLContext.cpp
@@ +951,5 @@
> +    }
> +    if (aSize.height < 64) {
> +      aSize.height = 64;
> +    }
> +#endif

I don't know the TiledTextureImage code well enough to say whether this is safe or not.

Comment 31

[Diego Wilson [:diego]]

(In reply to Sotaro Ikeda [:sotaro] from comment #29)
> Diego, do you know whether qcom's gpu have a restriction to minimum texture
> size?

Not AFAIK. You can render a 1x1 texture. Note, though, that the memory behind that texture may be bigger than the minimum for your texture size, as different formats may have certain memory requirements internally.

Comment 32

[Jeff Muizelaar [:jrmuizel]]

(In reply to Diego Wilson [:diego] from comment #31)
> (In reply to Sotaro Ikeda [:sotaro] from comment #29)
> > Diego, do you know whether qcom's gpu have a restriction to minimum texture
> > size?
> 
> Not AFAIK. You can render a 1x1 texture. Note, though, that the memory
> behind that texture may be bigger than the minimum for your texture size, as
> different formats may have certain memory requirements internally.

Even if that texture is backed by gralloc?

Comment 33

[Milan Sreckovic [:milan] (needinfo for best results)]

Also see bug 867674

Comment 34

[Diego Wilson [:diego]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #32)
> Even if that texture is backed by gralloc?

Our adreno graphic guys say that when you request a 1x1 gralloc buffers it should allocate a 32x32 buffer behind the scenes (HW restrictions for the stride). And that buffer should be fine for binding to a GL texture and rendering.

Are you having trouble with this on adreno hardware? If so, how are you allocating the buffer?

Comment 35

[Sotaro Ikeda [:sotaro]]

(In reply to Diego Wilson [:diego] from comment #34)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #32)
> > Even if that texture is backed by gralloc?
>
> Are you having trouble with this on adreno hardware? If so, how are you
> allocating the buffer?

A gralloc buffer is used for a Layer's drawing buffer. The buffer size is same as the layer size. Then the layer could be any size. Could be less than 32 width/height.

- ISurfaceAllocator::PlatformAllocSurfaceDescriptor()
http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp#344

Comment 36

[Diego Wilson [:diego]]

(In reply to Sotaro Ikeda [:sotaro] from comment #35)
> A gralloc buffer is used for a Layer's drawing buffer. The buffer size is
> same as the layer size. Then the layer could be any size. Could be less than
> 32 width/height.
> 
> - ISurfaceAllocator::PlatformAllocSurfaceDescriptor()
> http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/
> ShadowLayerUtilsGralloc.cpp#344

If this goes through standard GraphicBuffer allocation then it shouldn't be a problem. It should allocate a 1x1 buffer by backing it with 32x32. But the size to the client should still look like 1x1.

On the other hand, if the gralloc buffer is being allocated some other way, then it may not be backing it with a buffer size that the adreno drivers are expecting.

Comment 37

[Chris Lord [:cwiiis]]

Comment on attachment 760224 [details] [diff] [review]
patch for b2g18 - do not use gralloc buffer when texture is small

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

::: gfx/gl/GLContext.cpp
@@ +951,5 @@
> +    }
> +    if (aSize.height < 64) {
> +      aSize.height = 64;
> +    }
> +#endif

I don't think this should be done like this - I don't like the idea of allocating a TextureImage of a size AxB and having it result in a texture that isn't AxB. At the very least, this over-sizing should be masked somehow. I don't feel confident that this change wouldn't result in problems.

Can't this be fixed in the code that creates the texture instead?

Comment 38

[Sotaro Ikeda [:sotaro]]

Attachment: A screenshot of the problem did not happened case with layers borders

when mail's body is overflow and constructed as layer. This problem do not happen. It is strange...

Comment 39

[Wayne Chang [:wchang]]

Sotaro, do we have any progress here?

Comment 40

[Sotaro Ikeda [:sotaro]]

Attachment: temporary patch - extend ThebesLayerBuffer more than 64

The patch work in b2g18. In master symptom becomes better but still present.

Comment 41

[Sotaro Ikeda [:sotaro]]

Attachment: patch v2 - extend ThebesLayerBuffer's height to more than 64

Confirmed that the patch works for master and b2g18 on unagi.

Comment 42

[Sotaro Ikeda [:sotaro]]

FYI, nexus 4 does not have this problem.

Comment 43

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 772919 [details] [diff] [review]
patch v2 - extend ThebesLayerBuffer's height to more than 64

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

::: gfx/layers/ThebesLayerBuffer.cpp
@@ +182,5 @@
> +#ifdef MOZ_WIDGET_GONK
> +  // Some GL implementations fail to render gralloc textures with
> +  // width < 64 or height < 64.
> +  rect.height = std::max(aRequestedRect.height, 64);
> +#endif

We should really only do this on hardware where this problem happens. I'm not sure how to find out that list. It would also be good to confirm exactly which values of height it is broken for. You should also add this bug number to the comment about the failure.

Comment 44

[Alex Keybl [:akeybl]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #43)
> Comment on attachment 772919 [details] [diff] [review]
> patch v2 - extend ThebesLayerBuffer's height to more than 64
> 
> Review of attachment 772919 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/layers/ThebesLayerBuffer.cpp
> @@ +182,5 @@
> > +#ifdef MOZ_WIDGET_GONK
> > +  // Some GL implementations fail to render gralloc textures with
> > +  // width < 64 or height < 64.
> > +  rect.height = std::max(aRequestedRect.height, 64);
> > +#endif
> 
> We should really only do this on hardware where this problem happens. I'm
> not sure how to find out that list. It would also be good to confirm exactly
> which values of height it is broken for. You should also add this bug number
> to the comment about the failure.

We can allow partners to enable/disable as necessary, if we can't figure it out programatically.

Sotaro, can you help push this over the line?

Comment 45

[Sotaro Ikeda [:sotaro]]

Ok, I focus to this bug from today.

Comment 46

[Sotaro Ikeda [:sotaro]]

I created a test page to check the problem.
http://people.mozilla.org/~sikeda/test_input_height.html

Comment 47

[Sotaro Ikeda [:sotaro]]

Checked the problem on some Firefox OS devices.

--------------------------------
- v1.1 unagi hw composer disabled
  test page: problem from 9px to 16px
  gmail: the problem happened 

- v1.1 hamachi hw composer disabled
  test page: problem from 9px to 16px
  gmail: the problem happened

- v1.1 hamachi hw composer enabled
  test page: no problem
  gmail: the problem sometimes happened
         it seems almost random

- master hamachi hw composer disabled
  test page: problem from 9px to 16px
  gmail: the problem happened

- v1.1 leo hw composer disabled
  test page: problem from 9px to 16px
  gmail: the problem happened

- v1.1 leo hw composer enabled
  test page: no problem
  gmail: the problem sometimes happened
         it seems almost random

- master nexus4 hw composer disabled
  test page: no problem
  gmail: no problem

Comment 48

[Sotaro Ikeda [:sotaro]]

From comment #47, it becomes clear
 - The problem happens of OpenGL on all Firefox OS devices except nexus4
 - The problem happens when height is from 9px to 16px
     All symptoms on the devices except nexus 4 were same.
 - no problem at Hw Composer drawing
 - no problem on nexus 4

When hw composer is enabled, there is a cases that Texture is rendered by OpenGL.
It seems that the problem happens when OpenGL rendering was used on the devices in Hw composer enabled cases.

Comment 49

[Sotaro Ikeda [:sotaro]]

gralloc buffer's height is aligned to 32.(width is also aligned to 32)

https://github.com/mozilla-b2g/hardware_qcom_display/blob/master/libgralloc/alloc_controller.cpp#L343

Comment 50

[Sotaro Ikeda [:sotaro]]

Following GPUs are used in each Firefox OS devices.
- Unagi:   Adreno (TM) 200 
- Hamachi: Adreno (TM) 200
- Leo:     Adreno (TM) 200
- nexus4:  Adreno (TM) 320

Comment 51

[Sotaro Ikeda [:sotaro]]

From comment #50, the problem is caused by "Adreno (TM) 200". And is is enough to fix the problem only for Adreno 200.

Comment 52

[Sotaro Ikeda [:sotaro]]

Attachment: patch v3 - extend ThebesLayerBuffer's height to more than 32

Update the patch from analysis of the problem.

Comment 53

[Sotaro Ikeda [:sotaro]]

Attachment: patch v4 - extend ThebesLayerBuffer's height to more than 32

Change comment a little bit. Carry "jmuizelaar: review+".

Comment 54

[Sotaro Ikeda [:sotaro]]

Attachment: patch v4 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Patch for b2g18. Carry "jmuizelaar: review+".

Comment 55

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=09cbaee4e760

Comment 56

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/projects/birch/rev/b86c8fc67f5b

Comment 57

[Ryan VanderMeulen [:RyanVM]]

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

Comment 58

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/489c1aed4461

Comment 59

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/489c1aed4461

Comment 60

[Ryan VanderMeulen [:RyanVM]]

Backed out due to bug 895976. Might want to think of possible ways to write a test for the regression this caused, FWIW.
https://hg.mozilla.org/projects/birch/rev/cac24283746e
https://hg.mozilla.org/releases/mozilla-b2g18/rev/58a545e44ac0

Comment 61

[Sotaro Ikeda [:sotaro]]

I confirmed that the problem happened only on b2g18. No problem on master.

Comment 62

[Sotaro Ikeda [:sotaro]]

I checked ComputeBufferRect() by debugging. There is a cases that width and height is 0. It seems that this makes the problem.

Comment 63

[Sotaro Ikeda [:sotaro]]

Attachment: patch v5 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Fix the problem of Bug 895976. Confirmed on v1.1 hamachi. It is not clear the patch is correct fix.

Comment 64

[Gabriele Svelto [:gsvelto] (PTO)]

We did something similar in bug 884188 and I fear we're rolling in too many workarounds for this issue. We're now rounding the allocation size both here:

https://mxr.mozilla.org/mozilla-central/source/gfx/layers/ThebesLayerBuffer.cpp#447

... and here:

https://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp#380

Note that this change also required other changes to work which were part of attachment 774006 [details] [diff] [review]. We back-ported this patch to mozilla-b2g18 and the various bits are part of both bug 884188 and bug 885345.

Either way we should find what's the best way around this issue, remove the other workaround(s) and possibly narrow it only to the GPU / driver combination that is affected.

Comment 65

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #60)
> Backed out due to bug 895976. Might want to think of possible ways to write
> a test for the regression this caused, FWIW.
> https://hg.mozilla.org/projects/birch/rev/cac24283746e
> https://hg.mozilla.org/releases/mozilla-b2g18/rev/58a545e44ac0

Since this backout, B2G debug mochitests have been perma-orange with the following assert:
[Child 982] ###!!! ABORT: Swapped-in buffer size doesn't match old buffer's!: 'newSize == prevSize', file /builds/slave/m-b18-ics_a7_g-d-0000000000000/build/gfx/layers/basic/BasicBuffers.h, line 52

https://tbpl.mozilla.org/php/getParsedLog.php?id=25523929&tree=Mozilla-B2g18

Any ideas why this might be happening?

Comment 66

[Sotaro Ikeda [:sotaro]]

(In reply to Gabriele Svelto [:gsvelto] from comment #64)
> We did something similar in bug 884188 and I fear we're rolling in too many
> workarounds for this issue. We're now rounding the allocation size both here:

Confirmed that bug 884188 is fixed. And my patch was already backed out. I feel it is better to set this bug as dup of bug 884188.

I did not think about extend buffer at ISurfaceAllocator::PlatformAllocSurfaceDescriptor() from Comment 37.

Comment 67

[Sotaro Ikeda [:sotaro]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #65)
> Since this backout, B2G debug mochitests have been perma-orange with the
> following assert:
> https://tbpl.mozilla.org/php/getParsedLog.php?id=25523929&tree=Mozilla-B2g18
> 
> Any ideas why this might be happening?

It might happen because of bug 884188. The bug extend the buffer size only on parent side not at client side.

Comment 68

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #67)
> 
> It might happen because of bug 884188. The bug extend the buffer size only
> on parent side not at client side.

bug 884188 was committed same time to this bug. See Bug 895976 comment #4.

Comment 69

[Ed Morley [:emorley]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #60)
> Backed out due to bug 895976. Might want to think of possible ways to write
> a test for the regression this caused, FWIW.
> https://hg.mozilla.org/projects/birch/rev/cac24283746e
> https://hg.mozilla.org/releases/mozilla-b2g18/rev/58a545e44ac0

Backout merged:
https://hg.mozilla.org/mozilla-central/rev/cac24283746e

Comment 70

[Ryan VanderMeulen [:RyanVM]]

(In reply to Sotaro Ikeda [:sotaro] from comment #68)
> bug 884188 was committed same time to this bug. See Bug 895976 comment #4.

The mochitests didn't start failing until this was backed out. Are you saying that bug 884188 depends on this patch somehow? Regardless, b2g18 is closed until this is resolved.

Comment 71

[Sotaro Ikeda [:sotaro]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #70)
> (In reply to Sotaro Ikeda [:sotaro] from comment #68)
> > bug 884188 was committed same time to this bug. See Bug 895976 comment #4.
> 
> The mochitests didn't start failing until this was backed out. Are you
> saying that bug 884188 depends on this patch somehow? Regardless, b2g18 is
> closed until this is resolved.

Yes, until backout, all ThebesLayerBuffer's height is changed to 32. Then ThebesLayerBuffer's graloc buffer allocation does not hit bug 884188's change. Since backout, ThebesLayerBuffer's graloc buffer's height could be less than 32 at ShadowLayerForwarder::PlatformAllocBuffer() on b2g18.

Comment 72

[Ryan VanderMeulen [:RyanVM]]

Should I backout bug 884188 for now or wait on this bug to re-land whenever it gets r+?

Comment 73

[Sotaro Ikeda [:sotaro]]

Gabriele, how do you think about comment #72?

Comment 74

[Gabriele Svelto [:gsvelto] (PTO)]

Have we figured out if this bug was caused by attachment 777141 [details] [diff] which enalrged the gralloc'd buffer or attachment 778253 [details] [diff] which adjusted ShadowImageLayerOGL::GetRenderState() to cope with the larger buffer? I think it should be pretty safe to back-out attachment 777141 [details] [diff] if it's causing the problem as it should have no side-effects save un-fixing bug 884188.

BTW we landed these changes on both central and b2g18; did this problem not show up on central? Is this b2g18-specific?

Comment 75

[Sotaro Ikeda [:sotaro]]

(In reply to Gabriele Svelto [:gsvelto] from comment #74)
> Have we figured out if this bug was caused by attachment 777141 [details] [diff]
> [diff] [review] which enalrged the gralloc'd buffer or attachment 778253 [details] [diff]
> [details] [diff] [review] which adjusted
> ShadowImageLayerOGL::GetRenderState() to cope with the larger buffer? I
> think it should be pretty safe to back-out attachment 777141 [details] [diff]
> [diff] [review] if it's causing the problem as it should have no
> side-effects save un-fixing bug 884188.

attachment 777141 [details] [diff] was already backed out. By the back-out, attachment 778253 [details] [diff] made the problem on the test.

Comment 76

[Sotaro Ikeda [:sotaro]]

> attachment 777141 [details] [diff] was already backed out. By the
> back-out, attachment 778253 [details] [diff] made the problem on
> the test.

sorry, the above comment is my mistake. I misunderstand it is attachment 777765 [details] [diff] [review]. Please forget about it.

Comment 77

[Sotaro Ikeda [:sotaro]]

(In reply to Gabriele Svelto [:gsvelto] from comment #74)
> Is this b2g18-specific?

Crash happens here. This file is not present in master since gfx layers refactoring.
http://mxr.mozilla.org/mozilla-b2g18/source/gfx/layers/basic/BasicBuffers.h#51

Comment 78

[Ryan VanderMeulen [:RyanVM]]

Confirming that the backout of bug 884188 fixed the mochitest orange on b2g18.

Comment 79

[Sotaro Ikeda [:sotaro]]

attachment 777766 [details] [diff] [review] was back-out because of the regressio(Bug 895976)n on b2g18. After the backt-out, I recognized that bug 884188 could also fix this bug and I expect to close by the fix of bug 884188. But bug 884188 is also backed-out because of another regression. By this back-out, it become clear that we need fix this problem at least on b2g18.

Comment 80

[Sotaro Ikeda [:sotaro]]

Attachment: patch v6 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Fix not to happen regression b2g18.
- if request buffer size of height is 0, do not extend the height.

Comment 81

[Sotaro Ikeda [:sotaro]]

Comment on attachment 780492 [details] [diff] [review]
patch v6 for b2g18 - extend ThebesLayerBuffer's height to more than 32

I am going to update the patch for adding a comment.

Comment 82

[Sotaro Ikeda [:sotaro]]

Attachment: patch v7 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Update a comment.

Comment 83

[Sotaro Ikeda [:sotaro]]

Attachment: patch v7 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Previous patch was incorrect one. Replace by a correct patch.

Comment 84

[Sotaro Ikeda [:sotaro]]

Attachment: patch v7 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Comment 85

[Sotaro Ikeda [:sotaro]]

Need to confirm that attachment 780529 [details] [diff] [review] does not regress bug 895976 and Bug 896004 on b2g18.

Comment 86

[Sotaro Ikeda [:sotaro]]

Confirmed that attachment 780529 [details] [diff] [review] does not regress on v1.1 unagi, hamachi, leo.

Comment 87

[Sotaro Ikeda [:sotaro]]

Attachment: patch v8 for b2g18 - extend ThebesLayerBuffer's height to more than 32

Add header to a patch. Carry "jmuizelaar: review+".

Comment 88

[Sotaro Ikeda [:sotaro]]

https://tbpl.mozilla.org/?tree=Try&rev=ce8a9f8e4019

Comment 89

[Sotaro Ikeda [:sotaro]]

Confirmed no regression of Bug 895976 and Bug 896004 by attachment 781201 [details] [diff] [review] on v1.1 unagi, hamachi, leo.

Comment 90

[Sotaro Ikeda [:sotaro]]

check in is necessary only for b2g18. The master's bug will be fixed in Bug 884188.

Comment 91

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/91e7d386f754

Comment 92

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/91e7d386f754