732564 - [maple] Get viewport handling good again

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Make the viewport work as per The Plan(TM). The Plan(TM) can be found at https://wiki.mozilla.org/Fennec/NativeUI/Viewport

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 1 - Kill paint suppression code in browser.js

I'm leaving the paintingSuppressed hook on MetadataProvider in for now in case we need it for suppression during rotation, but if we end up not needing it at all then I can take it out.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 2 - Remove JS-driven redraw

This patch is a dupe of https://bug731897.bugzilla.mozilla.org/attachment.cgi?id=601976 but it needs to go after we remove paint suppression or things may break.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 3 - Merge update events from JS to Java since they do the same thing

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 4 - Some function rearranging

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 5 - Get rid of the updateViewport function

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 6 - Distinguish between updates that go to Java directly and that go via compositor

This patch depends on the patches in bug 732091

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 7 - Have the Viewport:Update message directly update the java viewport

This implements the goal of bug 731897. That bug can be duped to here as well, I think.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 8 - Take out java-side draw suppression during rotation

This method of doing draw suppression during rotation is not very robust or clean. Taking it out and we can implement this behaviour better later if it's needed.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 6 - Distinguish between updates that go to Java directly and that go via compositor

Oops, uploaded a wrong part 6.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 9 - Juggle some viewport-related logging

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 10 - Ignore user actions and viewport update events if browser content doc is not displayed

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 6 - Distinguish between updates that go to Java directly and that go via compositor

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 7 - Have the Viewport:Update message directly update the java viewport

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 8 - Take out java-side draw suppression during rotation

Comment 16

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 9 - Juggle some viewport-related logging

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 10 - Ignore user actions and viewport update events if browser content doc is not displayed

Comment 18

[Kartikaya Gupta (email:[e-mail])]

So with these patches there's still a bunch of weird behaviour. One of the main ones is how gecko's paint suppression code works. That is, it doesn't really suppress painting; it just suppresses painting of new documents for 250ms (or some preffed value) during some point in the page-loading period (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#1914).

What this means is that:
(1) if gecko is asked to paint, it will paint the *old* document instead of the new one during this period. (see http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsSubDocumentFrame.cpp#294). If we have already set the resolution on the pres shell (which we do currently) then this results in a visual glitch.
(2) if we haven't yet processed the meta viewport by that point, the page will glitch when we do process it and change the CSS viewport dimensions.

These appear to be the main reasons we have augmented paint suppression in browser.js.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 1 - Kill paint suppression code in browser.js

Apologies in advance for flooding your review queue...

Comment 21

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 2 - Remove JS-driven redraw

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 3 - Merge update events from JS to Java since they do the same thing

Comment 23

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 4 - Some function rearranging

Comment 24

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 5 - Get rid of the updateViewport function

Comment 25

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 6 - Distinguish between updates that go to Java directly and that go via compositor

Comment 26

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 7 - Have the Viewport:Update message synchronously update the java viewport

Comment 27

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 8 - Take out java-side draw suppression during rotation

Comment 28

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 9 - Ignore user actions and view update events if browser content doc is not displayed

Comment 29

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 10 - Move the document-shown event to be a before-first-paint event

Comment 30

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 11 - We need to clamp the viewport when animations are aborted to avoid overscroll

Comment 31

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 12 - Move the displayport stuff to Java and rework how it's done

Comment 32

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 13 - Update the display port when we get a new first-paint viewport

Comment 33

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 14 - Clean out the view resize handling codepath

Comment 34

[Kartikaya Gupta (email:[e-mail])]

So a few notes:
- A lot of the changes aren't really stand-alone in that they will introduce regressions without future patches in the sequence. However I left them as separate patches for ease of review; I'll probably fold everything into a single patch on landing rather than try to figure out which subsets of patches can be folded together.

- I think additional patches can be created to further optimize this behaviour (for example I think some of the events are sending properties that are now not being used any more). However those will not impact correctness and can be done as separate bugs to prevent this one from ballooning even more out of control.

- I have a build with all these patches applied (plus a patch that only touches logging) posted at people.mozilla.org/~kgupta/tmp/viewports.apk - currently it's based on an older maple revision but I'm building now with the patches applied to 4012267a4f08 and will updated that apk in-place with the new build.

- The wiki page at https://wiki.mozilla.org/Fennec/NativeUI/Viewport describes much of the design and caveats that go along with these patches. If you want to see any changes to that page let me know (or go ahead and edit the page directly). Also, the code tries to use terms that I defined in that document.

Comment 35

[Chris Lord [:cwiiis]]

Comment on attachment 603841 [details] [diff] [review]
Part 1 - Kill paint suppression code in browser.js

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

Looks fine.

Comment 36

[Chris Lord [:cwiiis]]

Comment on attachment 603842 [details] [diff] [review]
Part 2 - Remove JS-driven redraw

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

Looks fine.

Comment 37

[Chris Lord [:cwiiis]]

Comment on attachment 603844 [details] [diff] [review]
Part 3 - Merge update events from JS to Java since they do the same thing

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

Looks fine.

::: mobile/android/base/gfx/GeckoLayerClient.java
@@ +286,5 @@
>      /** Implementation of GeckoEventResponder. */
>      public String getResponse() {
>          // We are responding to the events handled in handleMessage() above with
> +        // the display port margins we want. Note that all messages we are currently
> +        // handling (Viewport:Update) require this

Would prefer to just reformat the whole comment rather than have this shorter second line. Nit-picking.

Comment 38

[Chris Lord [:cwiiis]]

Comment on attachment 603845 [details] [diff] [review]
Part 4 - Some function rearranging

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

r+ with comment addressed.

::: mobile/android/chrome/content/browser.js
@@ -1651,5 @@
>      };
>  
> -    // Update the viewport to current dimensions
> -    viewport.x = this.browser.contentWindow.scrollX || 0;
> -    viewport.y = this.browser.contentWindow.scrollY || 0;

Would rather not remove this, and s/Update/Set/ in the comment. Either that, or add the transform in-line too, but that'd look pretty messy...

Comment 39

[Chris Lord [:cwiiis]]

Comment on attachment 603847 [details] [diff] [review]
Part 5 - Get rid of the updateViewport function

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

Looks fine.

::: mobile/android/chrome/content/browser.js
@@ +2029,2 @@
>      // Ensure that when making changes to this function that code path
> +    // is not accidentally removed (the call to sendViewportUpdate() is at the

put at the on the next line, for neatness?

Comment 40

[Chris Lord [:cwiiis]]

Comment on attachment 603849 [details] [diff] [review]
Part 6 - Distinguish between updates that go to Java directly and that go via compositor

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

Looks fine.

Comment 41

[Chris Lord [:cwiiis]]

Comment on attachment 603852 [details] [diff] [review]
Part 7 - Have the Viewport:Update message synchronously update the java viewport

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

Not really sure how the page size stays in sync after this patch, but I assume that this is dealt with in a later patch.

::: mobile/android/base/gfx/GeckoLayerClient.java
@@ +255,5 @@
> +                synchronized (mLayerController) {
> +                    ViewportMetrics currentMetrics = new ViewportMetrics(mLayerController.getViewportMetrics());
> +                    currentMetrics.setOrigin(newMetrics.getOrigin());
> +                    currentMetrics.setZoomFactor(newMetrics.getZoomFactor());
> +                    currentMetrics.setPageSize(newMetrics.getPageSize());

Copying currentMetrics seems to be overkill just to retain the viewport size (and also isn't particularly clear without a comment).

Comment 42

[Chris Lord [:cwiiis]]

Comment on attachment 603854 [details] [diff] [review]
Part 8 - Take out java-side draw suppression during rotation

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

Looks fine and I always thought this code was a little suspect...

Comment 43

[Chris Lord [:cwiiis]]

Comment on attachment 603856 [details] [diff] [review]
Part 9 - Ignore user actions and view update events if browser content doc is not displayed

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

r+ with comment addressed.

::: mobile/android/chrome/content/browser.js
@@ +379,5 @@
>      CharacterEncoding.uninit();
>    },
>  
> +  // This function returns true during periods where the browser displayed document is
> +  // different from the browser content document, so user actions and some kinds of viewport

If this comment is correct, the function needs to be renamed - I would expect the opposite behaviour (returning false), going on the function name.

Comment 44

[Chris Lord [:cwiiis]]

Comment on attachment 603857 [details] [diff] [review]
Part 10 - Move the document-shown event to be a before-first-paint event

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

I'm not the right person to review this, though it looks fine to me.

Comment 45

[Chris Lord [:cwiiis]]

Comment on attachment 603860 [details] [diff] [review]
Part 11 - We need to clamp the viewport when animations are aborted to avoid overscroll

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

Looks good to me.

Comment 46

[Chris Lord [:cwiiis]]

Comment on attachment 603867 [details] [diff] [review]
Part 12 - Move the displayport stuff to Java and rework how it's done

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

Looks good.

::: mobile/android/base/gfx/GeckoLayerClient.java
@@ +92,3 @@
>          mScreenSize = new IntSize(0, 0);
>          mBufferSize = new IntSize(0, 0);
> +        mDisplayPort = new RectF(0, 0, 0, 0);

though it's consistent with the other two, none of the initialisation parameters are needed here.

Comment 47

[Chris Lord [:cwiiis]]

Comment on attachment 603868 [details] [diff] [review]
Part 13 - Update the display port when we get a new first-paint viewport

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

Looks ok. Although the comments are already good and lengthy, I think perhaps they could explain a bit more (but this is still r+ regardless). It took me a while to get my head around it, and I'm not sure if they're really understandable without a good knowledge of how the whole thing works.

Comment 48

[Chris Lord [:cwiiis]]

Comment on attachment 603870 [details] [diff] [review]
Part 14 - Clean out the view resize handling codepath

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

Looks good.

::: mobile/android/base/gfx/GeckoLayerClient.java
@@ +210,5 @@
>      void viewportSizeChanged() {
> +        // here we send gecko a resize message. The code in browser.js is responsible for
> +        // picking up on that resize event, modifying the viewport as necessary, and informing
> +        // us of the new viewport.
> +        sendResizeEventIfNecessary(true);

Do we ever call sendResizeEventIfNecessary(false) anymore?

Comment 49

[Chris Lord [:cwiiis]]

Excellent work :)

Comment 50

[Kartikaya Gupta (email:[e-mail])]

I've updated my local patches as described below.

> Part 3 - Merge update events from JS to Java since they do the same thing
> 
> Would prefer to just reformat the whole comment rather than have this
> shorter second line. Nit-picking.

Fixed.

> Part 4 - Some function rearranging
> 
> Would rather not remove this, and s/Update/Set/ in the comment. Either that,
> or add the transform in-line too, but that'd look pretty messy...

Moved the x and y assignment back out of the object declaration, and updated the comment.

> Part 5 - Get rid of the updateViewport function
> 
> put at the on the next line, for neatness?

Fixed.

> Part 7 - Have the Viewport:Update message synchronously update the java
> viewport
> 
> Not really sure how the page size stays in sync after this patch, but I
> assume that this is dealt with in a later patch.

It's actually dealt with in bug 732091, which starts calling setPageSize on GeckoLayerClient from the compositor as it finds out about updates to the page size. This replaces the previous path which updated the page size in beginDrawing()/endDrawing().

> Copying currentMetrics seems to be overkill just to retain the viewport size
> (and also isn't particularly clear without a comment).

This was a result of me not properly taking into account the introduction of ImmutableViewportMetrics. I've rearranged this so that we just apply the size from the layer controller's metrics to the new JSON-created metrics, and then set that as the metrics on the layer controller. This avoids the unnecessary copying. I also added a comment to clarify.

> Part 9 - Ignore user actions and view update events if browser content doc
> is not displayed
> 
> If this comment is correct, the function needs to be renamed - I would
> expect the opposite behaviour (returning false), going on the function name.

Whoops, the comment was out of date. I changed it say return false and also clarified when the period starts and ends, rather than referring to a "flag".

> Part 12 - Move the displayport stuff to Java and rework how it's done
> 
> though it's consistent with the other two, none of the initialisation
> parameters are needed here.

I took out the parameters on the line I added, but left the others as-is.

> Part 13 - Update the display port when we get a new first-paint viewport
> 
> Looks ok. Although the comments are already good and lengthy, I think
> perhaps they could explain a bit more (but this is still r+ regardless). It
> took me a while to get my head around it, and I'm not sure if they're really
> understandable without a good knowledge of how the whole thing works.

I rewrote the comments so that hopefully they are more clear; will upload updated patch.

> Part 14 - Clean out the view resize handling codepath
> 
> Do we ever call sendResizeEventIfNecessary(false) anymore?

We do still call it during initialization, and I think it might still be required there because (if I understand the code right) there's a race between the GeckoLayerClient coming up and the FlexibleGLSurfaceView getting the surfaceChanged notification, and having that call ensures we always set the size properly.

Comment 51

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 13 - Update the display port when we get a new first-paint viewport

Updated the comments in the patch; carrying r+

Comment 52

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 603857 [details] [diff] [review]
Part 10 - Move the document-shown event to be a before-first-paint event

s/Move/Rename/ and corresponding other wording changes in the checkin comment?  

And fix the C++ comments that still refer to document-shown, please.

r=me with that.

Comment 53

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 15 - Move first call to setDisplayPort

During the onLocationChange handler, the documentElement of the document is sometimes null. This resulted in the display port not getting set for the first paint, and the page would end up getting painted blurry because of a zoom level mismatch. This moves the call to setDisplayPort to just before the first paint so that this doesn't happen. (This should be folded into one of the previous patches, but keeping it separate for easier review).

Comment 54

[Chris Lord [:cwiiis]]

Comment on attachment 604205 [details] [diff] [review]
Part 15 - Move first call to setDisplayPort

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

Looks good to me.

Comment 55

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 10 - Add a before-first-paint event

https://hg.mozilla.org/integration/mozilla-inbound/rev/d8946e029410 adds a dependency on the document-shown event, so unfortunately I can't just get rid of it. It was first added in January, so it's already in beta and will be out the door shortly, and taking it out seems like it might break things that will come to depend on it. So instead I'm leaving it as-is and just adding the before-first-paint event on top of it. Re-requesting review.

Comment 57

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 16 - Ensure zoom from meta-viewport is correctly calculated

This fixes us rendering at odd zooms sometimes on rotation of a meta-viewport page (e.g. runfield). Also if you load a meta-viewport page after a non-meta-viewport page or vice-versa, we now reset the zoom and recalculate it properly.

Comment 58

[Chris Lord [:cwiiis]]

Comment on attachment 604456 [details] [diff] [review]
Part 16 - Ensure zoom from meta-viewport is correctly calculated

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

Looks good to me, I think...

Comment 59

[Timothy Nikkel (:tnikkel)]

So I'm just doing a review for bug 732091 and I have a question that seems like it should go here.

From what I can tell currently the first paint code is only used when switching between tabs. But it seems like the intention is to also use it while loading new pages. As https://wiki.mozilla.org/Fennec/NativeUI/Viewport points out (under Paint suppression) this is a  bit tricky. That page says "we detect the point at which the new document is about to be painted, and perform any necessary actions". I haven't been able to find this code. Did I overlook it? Or is it still upcoming?

Comment 60

[Kartikaya Gupta (email:[e-mail])]

Parts 6 and 10 contain the relevant code. In part 6, the document-shown event handler sets the first paint flag by calling displayedDocumentChanged(). In part 10 this code is changed to run on receipt of the before-first-paint event, which gets fired before the first paint of a newly loading page instead of the document-shown event which gets triggered after the paint.

Comment 61

[Timothy Nikkel (:tnikkel)]

Ah, ok, thank you.

Comment 62

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 604431 [details] [diff] [review]
Part 10 - Add a before-first-paint event

>+  nsBeforeFirstPaintDispatcher(nsCOMPtr<nsIDocument> aDocument)

Argument here should be just nsIDocument*.

r=me with that fixed, I guess, but check with the telemetry folks whether they really need the old event.  I'd really prefer to not fire them both...

Comment 63

[Mark Finkle (:mfinkle) (use needinfo?)]

> r=me with that fixed, I guess, but check with the telemetry folks whether
> they really need the old event.  I'd really prefer to not fire them both...


d8946e029410 was backed out and I did not see any other uses in MXR. Chances are also good that no add-ons are using "document-shown" yet.

Comment 64

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 1 - Kill paint suppression code in browser.js

Add r=Cwiiis to patch; no additional changes. Carrying r+

Comment 65

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 2 - Remove JS-driven redraw

Comment 66

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 3 - Merge update events from JS to Java since they do the same thing

Minor update to formatting of comments as per review comments. Add r=Cwiiis to patch. Carrying r+

Comment 67

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 4 - Some function rearranging

Rebase on latest maple. A recent m-c merge introduced a bunch of code that used tab.viewport which all needed to be changed to tab.getViewport(). Also updated with review comments and added r=Cwiiis to patch description.

Comment 68

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 5 - Get rid of the updateViewport function

Fix comment formatting as per review comments.

Comment 69

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 6 - Distinguish between updates that go to Java directly and that go via compositor

Rebase to account for how isFirstPaint is a boolean attribute on DOMWindowUtils rather than a function now.

Comment 70

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 7 - Have the Viewport:Update message synchronously update the java viewport

Update with review comments (remove extra ViewportMetrics creation).

Comment 71

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 8 - Take out java-side draw suppression during rotation

Comment 72

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 9 - Ignore user actions and view update events if browser content doc is not displayed

Updated some code comments as per review comments.

Comment 73

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 10 - Add a before-first-paint event

Change the nsCOMPtr<nsIDocument> to just an nsIDocument* as per bz's review comment. Also I talked to the Neil and he said he needs document-shown rather than before-first-paint so leaving that as-is.

Comment 74

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (:kats) from comment #73)
> Also I talked to the Neil and he said he needs document-shown

Err, that should be "to Neil" (from the telemetry team).

Comment 75

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 11 - We need to clamp the viewport when animations are aborted to avoid overscroll

Comment 76

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 12 - Move the displayport stuff to Java and rework how it's done

Minor updates for review comments.

Comment 77

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 13 - Update the display port when we get a new first-paint viewport

Comment 78

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 14 - Clean out the view resize handling codepath

Comment 79

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 15 - Move first call to setDisplayPort

Comment 80

[Kartikaya Gupta (email:[e-mail])]

Attachment: Part 16 - Ensure zoom from meta-viewport is correctly calculated

Comment 81

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/projects/maple/rev/8a20a89149ac
https://hg.mozilla.org/projects/maple/rev/278c638c3dcb
https://hg.mozilla.org/projects/maple/rev/d732ef6bebaa
https://hg.mozilla.org/projects/maple/rev/8e0e446b7d67
https://hg.mozilla.org/projects/maple/rev/32d74fbfbd8a
https://hg.mozilla.org/projects/maple/rev/a5980ce21d40
https://hg.mozilla.org/projects/maple/rev/8bcc8f581217
https://hg.mozilla.org/projects/maple/rev/212f97fe62cb
https://hg.mozilla.org/projects/maple/rev/be7d515d7902
https://hg.mozilla.org/projects/maple/rev/6d526bc48ffd
https://hg.mozilla.org/projects/maple/rev/18fa9efab290
https://hg.mozilla.org/projects/maple/rev/43427fc6f584
https://hg.mozilla.org/projects/maple/rev/57bf57e23475
https://hg.mozilla.org/projects/maple/rev/e245ceadedeb
https://hg.mozilla.org/projects/maple/rev/a10cdbee3dab
https://hg.mozilla.org/projects/maple/rev/8dad746ee562

Comment 82

[Kartikaya Gupta (email:[e-mail])]

Somehow got the wrong bug number on the last patch. Backed out and relanded with the right bug number.

https://hg.mozilla.org/projects/maple/rev/d8326d63c320
https://hg.mozilla.org/projects/maple/rev/e3798e906917