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

RESOLVED FIXED in 1.1 QE5

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: leo.bugzilla.gaia, Assigned: sotaro)

Tracking

({regression})

Trunk
1.1 QE5
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking-b2g:leo+, firefox23 wontfix, firefox24 wontfix, firefox25 wontfix, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd fixed)

Details

(Whiteboard: [TD-30810][apps watch list][3rd Party][LeoVB+])

Attachments

(3 attachments, 12 obsolete attachments)

27.65 KB, image/png
Details
35.49 KB, image/png
Details
1.59 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
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
Hi jason,

Please let know the scope of fixing this issue also how issues from such 3rd party applications are handled.
Flags: needinfo?(jsmith)
Whiteboard: [TD-30810]
Target Milestone: --- → 1.1 QE2
This doesn't reproduce on 1.01, so it's likely a gecko bug then.
Flags: needinfo?(jsmith)
Leo QE2 bug -- nominating for 1.1
blocking-b2g: --- → leo?
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.
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?
Flags: needinfo?(matt.woodrow)
(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.
Component: General → Layout
Product: Boot2Gecko → Core
Version: unspecified → Trunk
(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.
This issue might be a regression of 1.1
blocking-b2g: leo? → leo+
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?
Flags: needinfo?(matt.woodrow)
Keywords: regression
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
I've got a strong hunch bug 826829 broke this.

Sotaro - What do you think?
Flags: needinfo?(sotaro.ikeda.g)
(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.
Flags: needinfo?(sotaro.ikeda.g)
:nical, is ImageContainerChild used only for video frame rendering?
Flags: needinfo?(nical.bugzilla)
(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.)
Flags: needinfo?(nical.bugzilla)
Assignee: nobody → sotaro.ikeda.g
(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
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.
(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".
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.
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.
Assignee: sotaro.ikeda.g → nobody
I am going to investigate about the bug more.
QA Contact: sotaro.ikeda.g
I confirmed the problem happens also on "UI Tests -> text inputmode tests". On text input area that have low height.
(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.
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.
(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.
Confirmed the patch works on mster buri.
(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.
Confirmed that the patch fixes the problem on v1.1 buri. I am not sure whether this fix is correct.
Component: Layout → Graphics: Layers
Flags: needinfo?(bjacob)
Flags: needinfo?(bjacob)
Assignee: nobody → sotaro.ikeda.g
QA Contact: sotaro.ikeda.g
Attachment #760214 - Flags: review?(jmuizelaar)
Attachment #760224 - Flags: review?(jmuizelaar)
Diego, do you know whether qcom's gpu have a restriction to minimum texture size?
Flags: needinfo?(dwilson)
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.
Attachment #760224 - Flags: review?(jmuizelaar) → review?(chrislord.net)
(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.
Flags: needinfo?(dwilson)
(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?
(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?
(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
(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.
Target Milestone: 1.1 QE2 (6jun) → 1.1 QE3 (24jun)
Target Milestone: 1.1 QE3 (24jun) → ---
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?
Attachment #760224 - Flags: review?(chrislord.net) → review-
Whiteboard: [TD-30810] → [TD-30810][apps watch list]
when mail's body is overflow and constructed as layer. This problem do not happen. It is strange...
Whiteboard: [TD-30810][apps watch list] → [TD-30810][apps watch list][3rd Party]
Sotaro, do we have any progress here?
Flags: needinfo?(sotaro.ikeda.g)
Attachment #760214 - Attachment is obsolete: true
Attachment #760214 - Flags: review?(jmuizelaar)
Attachment #760224 - Attachment is obsolete: true
The patch work in b2g18. In master symptom becomes better but still present.
Flags: needinfo?(sotaro.ikeda.g)
Confirmed that the patch works for master and b2g18 on unagi.
Attachment #772146 - Attachment is obsolete: true
Attachment #772919 - Flags: review?(jmuizelaar)
FYI, nexus 4 does not have this problem.
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.
Attachment #772919 - Flags: review?(jmuizelaar) → review-
(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?
Flags: needinfo?(sotaro.ikeda.g)
Ok, I focus to this bug from today.
Flags: needinfo?(sotaro.ikeda.g)
I created a test page to check the problem.
http://people.mozilla.org/~sikeda/test_input_height.html
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
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.
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
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
From comment #50, the problem is caused by "Adreno (TM) 200". And is is enough to fix the problem only for Adreno 200.
Update the patch from analysis of the problem.
Attachment #772919 - Attachment is obsolete: true
Attachment #777353 - Flags: review?(jmuizelaar)
Attachment #777353 - Flags: review?(jmuizelaar) → review+
Change comment a little bit. Carry "jmuizelaar: review+".
Attachment #777353 - Attachment is obsolete: true
Attachment #777765 - Flags: review+
Attachment #777765 - Attachment description: patch_873937_4 → patch v4 - extend ThebesLayerBuffer's height to more than 32
Patch for b2g18. Carry "jmuizelaar: review+".
Attachment #777766 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/b86c8fc67f5b
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Depends on: 895976
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
Status: RESOLVED → REOPENED
Flags: in-testsuite?
Resolution: FIXED → ---
Target Milestone: mozilla25 → ---
I confirmed that the problem happened only on b2g18. No problem on master.
I checked ComputeBufferRect() by debugging. There is a cases that width and height is 0. It seems that this makes the problem.
Fix the problem of Bug 895976. Confirmed on v1.1 hamachi. It is not clear the patch is correct fix.
Attachment #777765 - Attachment is obsolete: true
Attachment #777766 - Attachment is obsolete: true
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.
(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?
(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.
(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.
(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.
(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
(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.
(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.
Should I backout bug 884188 for now or wait on this bug to re-land whenever it gets r+?
Gabriele, how do you think about comment #72?
Flags: needinfo?(gsvelto)
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?
Flags: needinfo?(gsvelto)
(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.
> 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.
(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
Confirming that the backout of bug 884188 fixed the mochitest orange on b2g18.
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.
Fix not to happen regression b2g18.
- if request buffer size of height is 0, do not extend the height.
Attachment #778777 - Attachment is obsolete: true
Attachment #780492 - Flags: review?(jmuizelaar)
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.
Attachment #780492 - Flags: review?(jmuizelaar)
Update a comment.
Attachment #780492 - Attachment is obsolete: true
Attachment #780504 - Flags: review?(jmuizelaar)
Attachment #780504 - Flags: review?(jmuizelaar) → review-
Previous patch was incorrect one. Replace by a correct patch.
Attachment #780504 - Attachment is obsolete: true
Attachment #780525 - Flags: review?(jmuizelaar)
Attachment #780525 - Attachment is obsolete: true
Attachment #780525 - Flags: review?(jmuizelaar)
Attachment #780529 - Flags: review?(jmuizelaar)
Attachment #780529 - Flags: review?(jmuizelaar) → review+
Need to confirm that attachment 780529 [details] [diff] [review] does not regress bug 895976 and Bug 896004 on b2g18.
Confirmed that attachment 780529 [details] [diff] [review] does not regress on v1.1 unagi, hamachi, leo.
Add header to a patch. Carry "jmuizelaar: review+".
Attachment #780529 - Attachment is obsolete: true
Attachment #781201 - Flags: review+
Confirmed no regression of Bug 895976 and Bug 896004 by attachment 781201 [details] [diff] [review] on v1.1 unagi, hamachi, leo.
check in is necessary only for b2g18. The master's bug will be fixed in Bug 884188.
Keywords: checkin-needed
https://hg.mozilla.org/releases/mozilla-b2g18/rev/91e7d386f754
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 1.1 QE5
Whiteboard: [TD-30810][apps watch list][3rd Party] → [TD-30810][apps watch list][3rd Party][LeoVB+]
You need to log in before you can comment on or make changes to this bug.