Flags: needinfo?(botond@mozilla.co m) →

Botond Ballo [:botond] said:
(In reply to Botond Ballo [:botond] from comment #10) > (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > > Botond, if you have some time, can you throw this into a build and > > run it by Gordon to see if he likes it? > > Will do! I showed Gordon the modified build. The overall feeling was that it's definitely an improvement, but it still feels suboptimal. We tested the same page, https://www.apple.com/ios/ios8/, on Fennec and on B2G (without the reduced opacity), and observed that it looks quite a bit better on Fennec than on B2G. Gordon said that if we could get the B2G version to look like the Fennec one, it would be great. It seems the next step is to figure out what is the cause of the difference in look between Fennec and B2G. A first step might be to try the two side-by-side on the same device (the comparison we made was Nexus 4 running B2G vs. Galaxy Nexus running Fennec).

Botond Ballo [:botond] said:
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #12) > (In reply to Botond Ballo [:botond] from comment #11) > > We tested the same page, https://www.apple.com/ios/ios8/, on Fennec and on > > B2G (without the reduced opacity), and observed that it looks quite a bit > > better on Fennec than on B2G. Gordon said that if we could get the B2G > > version to look like the Fennec one, it would be great. > > Huh, that's interesting. As far as I know they use exactly the same code. One suggestion that was brought up (I think by Jeff) was that the difference could be in the platform's graphics stack, for example in how fonts are anti-aliased / hinted.

Last Resolved: → 2014-06-09 21:52:17

Resolution: --- → FIXED

Status: NEW → RESOLVED

Target Milestone: --- → mozilla33

Ryan VanderMeulen [:RyanVM UTC-4] said:
https://hg.mozilla.org/mozilla-central/rev/687e8799e88f

Last Resolved: → 2014-06-09 21:52:21

Resolution: --- → FIXED

Status: NEW → RESOLVED

Target Milestone: --- → mozilla33

Ryan VanderMeulen [:RyanVM UTC-4] said:
https://hg.mozilla.org/mozilla-central/rev/132e908c3a00 https://hg.mozilla.org/mozilla-central/rev/3239ce0fc365 https://hg.mozilla.org/mozilla-central/rev/9e5ae19a1e13 https://hg.mozilla.org/mozilla-central/rev/e26cfd8267fa

depbug-1018387-Status: NEW → RESOLVED

depbug-1018387-Resolution: --- → FIXED

Attachment #8437312 Flags: review?(mark.finkle@gmail.c om) → review+

Mark Finkle (:mfinkle) said:
Comment on attachment 8437312 --> https://bugzilla.mozilla.org/attachment.cgi?id=8437312 patch v1: reenable/reimplement app uninstallation from about:apps Android parts look good. Bonus points for Monopoly-inspired comments.

Attachment #8437312 Flags: review?(mar.castelluccio@st udenti.unina.it) → review+

Marco Castelluccio [:marco] said:
Comment on attachment 8437312 --> https://bugzilla.mozilla.org/attachment.cgi?id=8437312 patch v1: reenable/reimplement app uninstallation from about:apps Review of attachment 8437312: --> (https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1019054&attachment=8437312) ----------------------------------------------------------------- r+ with the comment about doUninstall addressed. ::: dom/apps/src/Webapps.jsm @@ +327,5 @@ > + return; > + } > + let app = this.webapps[aResult.id]; > + app.csp = aResult.manifest.csp || ""; > + app.role = aResult.manifest.role || ""; This is another place where we're modifying the registry silently (like we did in _processManifestForIds). I'm not sure why we're doing this, we should probably file a bug and ask Fabrice. ::: mobile/android/modules/WebappManager.jsm @@ +234,5 @@ > + apkPackageName: app.apkPackageName, > + }); > + > + // We don't need to call DOMApplicationRegistry.doUninstall at this point, > + // because the APK uninstall listener will do it once the APK If you're calling doUninstall once the APK is uninstalled... @@ +239,5 @@ > + // is uninstalled; and if the user cancels the APK uninstallation, then we > + // shouldn't remove the app from the registry anyway. > + > + // But we should tell the requesting document the result of their request. > + // TODO: tell the requesting document if uninstallation succeeds or fails. ...you shouldn't need to send the result of the request here, as doUninstall will do it. Am I missing something? Anyway I think we should send the reply when the application is actually uninstalled, so when the APK is uninstalled.

Component: Gaia::E-Mail → Panning and Zooming

Product: Firefox OS → Core

blocking-b2g: 2.0? → 2.0+

Keywords: → reproducible

Milan Sreckovic [:milan] said:
Just to be clear, this is 2.0+ because it's a regression from 1.4, and this is a critical workflow?

No-Jun Park [:njpark] said:
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10) > (In reply to No-Jun Park [:njpark] from comment #3) > > The device is throttled to have 512MB of RAM > > Do we expect to ship devices with a Flame-like screen size with 512 MB of > RAM? > > The experience on Flame panning/zooming this email is indeed quite janky and > slow with 512 MB but is much better with 1024 MB. I haven't yet reproduced > the OOM crash though. tchung suggested that we should throttle the RAM of Flame device to 512, because apparently that would be the spec of the production device.

CC: → pcheng@qanalydocs.com

QA Contact: → pcheng@qanalydocs.com

Flags: → needinfo?(jsmith@mozilla.com)

Pi Wei Cheng said:
I will need confirmation on how to proceed to finding the window for this bug. The bug reproduces on today's 2.0 Flame, with and without APZ turned on. The bug reproduces on earliest Flame central tinderbox engineering build (4/17), but ONLY with APZ turned ON. It does NOT occur with APZ turned OFF. The bug reproduces on today's Buri 2.0 with and without APZ turned on. Would you like the window to be found in Flame, with APZ turned OFF? Or in Buri, with APZ turned ON? Since I see discussions about tweaking Flame memory, I wasn't sure if you guys want this bug exclusive to Flame. (I'm on v10g-2 base image and I've never tweaked my Flame's memory)

Flags: needinfo?(jsmith@mozilla.co m) →

Jason Smith [:jsmith] said:
I'd do the window on Buri since we've got more builds there.

Blocks: → 985541

CC: → dmitry.rojkov@gmail.com

Component: Gaia::Gallery → Panning and Zooming

Flags: → needinfo?(dmitry.rojkov@gmail.com)

Product: Firefox OS → Core

Version: unspecified → Trunk

Jason Smith [:jsmith] said:
Broken by bug 985541. Can you take a look? Referenced Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=985541 [Bug 985541] Turn GestureEventListener into finite-state machine

Flags: needinfo?(dmitry.rojkov@gma il.com) →

dmitry.rojkov@gmail.com said:
Does it happen only in Gallery? Can I reproduce the issue with a test html page. Unfortunately I don't have a ffos device to try to reproduce it. My changeset reduces the local state of GestureEventListener. Particularly the list GestureEventListener::mTouches gets cleared explicitly and populated again with fresh data upon every gesture start. Previously obsolete touch points could outlive gestures and the old version of GEL somehow handled them. Can it be that MultiTouchInput::MULTITOUCH_START events on Buri contain obsolete touch points?

No-Jun Park [:njpark] said:
Just to add, this happens in both Buri and Flame device.

CC: → bugmail.mozilla@staktrace.com, drs+bugzilla@sherk.me

CC: → tchung@mozilla.com

Tony Chung [:tchung] said:
this doesnt seem to affect the original horizontal homescreen.

CC: → bugmail.mozilla@staktrace.com

Avi Halachmi (:avih) said:
(In reply to :kip (Kearwood Gilbert) from comment #2) > During implementation, I noticed that the Mozilla extensions, > window.scrollByLines and window.scrollByPages, share much of the same > implementation. > > Would it be useful to add the ScrollOptions parameters for smooth scrolling > to those as well? If Gecko's internal lines/page scroll (e.g. in response to mouse wheel events or PgDown) use these extensions (or derivatives) internally, then I think it would be useful that either one of these happen: 1. They're converted to internally use scroll/scrollTo/scrollBy with ScrollOptions. or 2. scrollByLines and scrollByPages will use the ScrollOptions as comment 2 suggests. The reason being that the implementation of this feature might end up as based on APZ (async pan zoom) for smoother animation, and this could benefit automatically our page/lines scrolls in response to user inputs.

:kip (Kearwood Gilbert) said:
(In reply to Avi Halachmi (:avih) from comment #3) > (In reply to :kip (Kearwood Gilbert) from comment #2) > > During implementation, I noticed that the Mozilla extensions, > > window.scrollByLines and window.scrollByPages, share much of the same > > implementation. > > > > Would it be useful to add the ScrollOptions parameters for smooth scrolling > > to those as well? > > If Gecko's internal lines/page scroll (e.g. in response to mouse wheel > events or PgDown) use these extensions (or derivatives) internally, then I > think it would be useful that either one of these happen: > > 1. They're converted to internally use scroll/scrollTo/scrollBy with > ScrollOptions. > > or > > 2. scrollByLines and scrollByPages will use the ScrollOptions as comment 2 > suggests. > > The reason being that the implementation of this feature might end up as > based on APZ (async pan zoom) for smoother animation, and this could benefit > automatically our page/lines scrolls in response to user inputs. Internally, these functions are based on scrollTo. It is just a matter of passing ScrollOptions through.

Botond Ballo [:botond] said:
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5) > Could we just bail out at > http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/ > APZCTreeManager.cpp#544 if mApzcForInputBlock is non-null and in overscroll? Interesting suggestion. I think what would happen though is subsequent touch-moves for either finger would be processed by the overscrolled APZC while in the PANNING state, resulting in erratic panning.

Assignee: nobody@mozilla.org → mstange@themasta.com

Blocks: → 1019737

Flags: needinfo?(mstange@themasta. com) →

Status: NEW → ASSIGNED

Markus Stange [:mstange] said:
This is the offending changeset: http://hg.mozilla.org/integration/mozilla-inbound/rev/083854f3d590 Referenced Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1019737 [Bug 1019737] Only layerize the scrollbar thumb if the target scroll frame has active scrolling

CC: → jypenator@gmail.com

Keywords: → dev-doc-needed

Danny Liang [:dliang] said:
Facebook was killed by LMK due to free swap is low, so bug 1016212 helps, the commit as below: commit 4c82f1be5aafc5a102a3c3d98a641e0724683abe Author: ying.xu <ying.xu@spreadtrum.com> Date: Tue Jun 3 15:56:55 2014 +0800 Bug#303502 don't kill foreground apps when free of swap disk low [self test ] no killing when free of swap disk low Change-Id: I701e1490201793cd6666a149b9f8d530922dc1b6

Flags: needinfo?(ying.xu@spreadtru m.com) →

ying.xu said:
It took me sometime to login facebook with latest build and facebook app, I can add 5+ photos from gallery or camera. without facebook being killed. And I don't find any crop operations with 5.30 kernel image and latest facebook app, I can add 5+ photos from gallery or camera. without facebook being killed. logs with latest build and facebook app apusr@yingxuubt:~/b2gsource/ffos/monkey.test/test-config$ adb shell procrank PID Vss Rss Pss Uss cmdline 85 33472K 30704K 26326K 22284K /system/b2g/b2g 2636 31128K 30584K 26252K 22228K /system/b2g/b2g 298 924K 924K 476K 260K /system/b2g/b2g 2958 436K 432K 284K 232K procrank ------ ------ ------ 54947K 46356K TOTAL RAM: 100396K total, 3948K free, 48K buffers, 24916K cached, 2208K shmem, 5524K slab apusr@yingxuubt:~/b2gsource/ffos/monkey.test/test-config$ adb shell b2g-ps APPLICATION USER PID PPID VSIZE RSS WCHAN PC NAME b2g root 85 1 134032 30708 ffffffff 40152518 S /system/b2g/b2g (Nuwa) root 298 85 46964 928 ffffffff 40152518 S /system/b2g/b2g Facebook app_2636 2636 298 81820 30584 ffffffff 40152518 S /system/b2g/b2g apusr@yingxuubt:~/b2gsource/ffos/monkey.test/test-config$ adb shell cat /proc/meminfo MemTotal: 100396 kB MemFree: 4104 kB Buffers: 48 kB Cached: 24860 kB SwapCached: 2216 kB Active: 27144 kB Inactive: 31580 kB Active(anon): 18220 kB Inactive(anon): 26328 kB Active(file): 8924 kB Inactive(file): 5252 kB Unevictable: 332 kB Mlocked: 0 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 100396 kB LowFree: 4104 kB SwapTotal: 65532 kB SwapFree: 27484 kB

ying.xu said:
Created attachment 8437613 --> https://bugzilla.mozilla.org/attachment.cgi?id=8437613&action=edit facebook-addphoto a snapshot of my test Can you people confirm whether the facebook app was updated?

Flags: needinfo?(jruderman@gmail.c om) →

Last Resolved: → 2014-06-09 19:59:52

Resolution: --- → WORKSFORME

Status: NEW → RESOLVED

Jesse Ruderman said:
Same on Mac (printing only). Bug 468851 covers that error message.

Attachment is obsolete: 0 → 1

Attachment #8436542 Flags: review?(terrence@mozilla.co m) → review?(terrence@mozilla.com)

Emanuel Hoogeveen [:ehoogeveen] said:
Created attachment 8437417 --> https://bugzilla.mozilla.org/attachment.cgi?id=8437417&action=edit v2 - Sort arenas in order of increasing free space. Running with the "Visualize arenas" patch Nicholas mentioned showed that my size calculation was too naive - and how to fix it, too. This patch fixes that, and I can see it working as expected. I haven't got any results on potential memory savings yet, though. I've been trying to think what a good way to test this would be. Octane is a pretty good stress test for the garbage collector, but once it's done I wouldn't expect us to hang on to any of the memory it used, so that should free all the arenas that weren't already in use to begin with. Where this *should* make a difference is in loading websites that use a lot of JS. Their arena usage will peak while the pages are loading, but they should hang on to some results, leaving behind partially filled arenas. I'll probably try membench tomorrow and see if the patch makes a clear difference - unfortunately, that loads so many pages that I expect the result will be quite noisy.

Nicholas Nethercote [:njn] said:
techcrunch.com is my preferred test case when I need a large page with lots of JS. Make sure you roll over the social media button strip at the bottom of each story so that all the buttons get loaded.

CC: → spmbox1@gmail.com

spmbox1@gmail.com said:
Windows XP x86 Firefox v29.0.1 Workarounds stopped working starting with version 28. 2014-06-10 still no fix. Pages load slowly. It appears that about:config was crippled. "gfx.content.azure.enabled" does nothing, dummy option. This is not the only option. For example, another option is "browser.fixup.alternate.enabled", it doesn't work, Fx adds www and com when you quickly copy/paste a word into address bar, and when you clean "browser.fixup.alternate.prefix" and "browser.fixup.alternate.suffix", Fx still adds www I wonder why developers did that?

spmbox1@gmail.com said:
I see no edit option for comments, hmm.. I just wanted to add, my graphics card is nVidia GeForce 4 MX 440 (on AGP8x) driver (forceware) version: 93.71 (I think that is the latest official driver). Firefox worked fine up to Fx v26, starting with Fx v27 pages started loading very slowly, fixed using gfx.content.azure.enabled solution (by removing cairo), starting with Fx v28 old fixes doesn't work, no new fixes up to this day, June 10th (Fx v29).

Flags: needinfo?(bzbarsky@mit.edu) →

Boris Zbarsky [:bz] said:
I think generally necko should drop references to everything it can when it sends OnStopRequest, because that's the only way to prevent leaks through non-cycle-collected channel objects... That does mean that hanging on to channels that you set stuff on but never open is bad.

Kyle Huey [:khuey] (khuey@mozilla.com) said:
I would kind of like to start cycle collecting channels at some point in the future.

Depends on: → 1023058

depbug-1021290-Status: NEW → RESOLVED

depbug-1021290-Resolution: --- → FIXED

Attachment #8430054 Flags: review?(dholbert@mozilla.co m) → review-

Daniel Holbert [:dholbert] said:
Comment on attachment 8430054 --> https://bugzilla.mozilla.org/attachment.cgi?id=8430054 PresShell::mFrameConstructor Marking r- on the PresShell::mFrameConstructor patch, to make per comment 23 explicit & remove this from my review queue. :) (This is close, though, I think.)

OS: Gonk (Firefox OS) → All

Hardware: ARM → All

Cameron McCormack (:heycam) said:
https://hg.mozilla.org/integration/mozilla-inbound/rev/33ce82daa572 https://hg.mozilla.org/integration/mozilla-inbound/rev/b6cd0caaf182 https://hg.mozilla.org/integration/mozilla-inbound/rev/a98e6f80344c

Last Resolved: → 2014-06-09 23:18:11

Resolution: --- → WONTFIX

Status: NEW → RESOLVED

Karl Tomlinson (needinfo?:karlt) said:
(In reply to Frederic Plourde (:fred23) from comment #74) > If not, I'd close this bug as WONTFIX because > 1) the MTC path is dying > 2) anyways, even if we patch this, the patch is already posted in the OMTC > side and will be reviewed and pushed as part of the Bug 1015218. Sounds good. Bug 1015218 seems a better place for attachment 8429555 because there it can add some additional configuration to UseXRender().

depbug-738937-Status: NEW → RESOLVED

depbug-738937-Resolution: --- → WONTFIX

j.parkouss@gmail.com said:
(In reply to William Lachance (:wlach) from comment #30) > Hey! So I checked out your changes and things look mostly good. The most > immediate problem is that we're not bisecting inbound builds by default, I > guess because b2g is not marked as supporting inbound here: > > https://github.com/mozilla/mozregression/blob/master/mozregression/ > regression.py#L163 > > I think if you fix that it should "just work". You can verify that by doing > something like: > > mozregression -n b2g -g 2014-06-07 -b 2014-06-08 Woops, I missed that. :) It's corrected. I tested it and all seems to goes well. I'd like to work on bug 1022720 and then on bug 1022885 to be able to report gaia revision information in desktop builds.

CC: → sven.reimers@gmail.com

Sven said:
Any further updates on this issue? I still see this in FireFox 29.0.1 on Windows with latest JIRA installation.

Last Resolved: → 2014-06-10 01:16:57

Resolution: --- → DUPLICATE

Status: NEW → RESOLVED

Dão Gottwald [:dao] said:
*** This bug has been marked as a duplicate of bug 993387 *** Referenced Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=993387 [Bug 993387] All active / hovered menu items stay highlighted, if using a Windows high-contrast color theme

Attachment is obsolete: 1 → 0

Attachment is obsolete: 0 → 1

:Gijs Kruitbosch said:
Created attachment 8437533 --> https://bugzilla.mozilla.org/attachment.cgi?id=8437533&action=edit take transforms into account for popup placement, Alright, so I think this is what you meant... but I could be wrong - let's find out: https://tbpl.mozilla.org/?tree=Try&rev=232be2a8a44b

Attachment is obsolete: 0 → 1

Attachment #8437533 Flags: → review?(bzbarsky@mit.edu),feedback?(tnikkel@gmail.com)

:Gijs Kruitbosch said:
Comment on attachment 8437533 --> https://bugzilla.mozilla.org/attachment.cgi?id=8437533 take transforms into account for popup placement, This is looking better - green m-other tests... tn, was this what you meant? :-)

TBPL Robot said:
edmorley https://tbpl.mozilla.org/php/getParsedLog.php?id=41414962&tree=Mozilla-Inbound Windows 7 32-bit mozilla-inbound debug test crashtest on 2014-06-09 23:38:19 revision: 100a14518e5b slave: t-w732-ix-108 REFTEST TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/gfx/tests/crashtests/815489.html | assertion count 4 is more than expected 0 to 1 assertions

TBPL Robot said:
edmorley https://tbpl.mozilla.org/php/getParsedLog.php?id=41414300&tree=Fx-Team Android 4.0 Panda fx-team debug test mochitest-8 on 2014-06-09 23:28:33 revision: 9dc0ffca10f4 slave: panda-0704 Caught Exception: Remote Device Error: unable to connect to panda-0704 after 5 attempts PROCESS-CRASH | /tests/layout/style/test/test_media_queries.html | application crashed [@ nsNodeInfo::Release()] 06-09 23:43:09.312 F/MOZ_Assert( 2247): Assertion failure: int32_t(mRefCnt) > 0 (dup release), at /builds/slave/fx-team-and-d-0000000000000000/build/content/base/src/nsNodeInfo.cpp:166 Return code: 1 06-09 23:43:09.312 F/MOZ_Assert( 2247): Assertion failure: int32_t(mRefCnt) > 0 (dup release), at /builds/slave/fx-team-and-d-0000000000000000/build/content/base/src/nsNodeInfo.cpp:166

TBPL Robot said:
edmorley https://tbpl.mozilla.org/php/getParsedLog.php?id=41429414&tree=Mozilla-Inbound Android 4.0 Panda mozilla-inbound debug test mochitest-3 on 2014-06-10 02:47:18 revision: 64553c483cd1 slave: panda-0568 Caught Exception: Remote Device Error: unable to connect to panda-0568 after 5 attempts 1000 INFO TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_error_in_video_document.html | Network state - got 2, expected 0 1001 INFO TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_error_in_video_document.html | Error object - didn't expect null, but got it

Flags: needinfo?(ttaubert@mozilla. com) →

Tim Taubert [:ttaubert] said:
(In reply to David Rajchenbach Teller [:Yoric] from comment #4) > > > + // As we are not sure that we are the only ones touching `state`, > > > + // we need to remove any possible aliasing. > > > + state = Cu.cloneInto(state, {}); > > > > Cloning the whole state seems costly. Measurements in bug 972243 suggest > > that this may have a non-negligible overhead, esp. for big sessions. > > Indeed, we win only if this clearly faster than JSON.stringify on the same > object. Well before your patch we were calling JSON.stringify() once, now we're additionally doing a structured clone. That doesn't feel better to me? > > Why can't we just call _writeState() off of the next tick if we wanted to > > split these steps? That means we could do that without touching/rewriting > > the whole function. > > Because we have no guarantee that `state` won't be touched in the meantime > by any event handler, do we? > Now, we could add a lock "don't touch any data structure while we're > writing". It's just more complicated. Yeah, no locks, please :) > Certainly, the largest win is yield just after "// Collection is complete. > We may now be safely interrupted." in `_saveState`. This additional cut is > basically because it's free. It doesn't feel free to me judging by how much code we have to touch for that. Looks more complicated too.

David Rajchenbach Teller [:Yoric] said:
(In reply to Tim Taubert [:ttaubert] from comment #6) > Well before your patch we were calling JSON.stringify() once, now we're > additionally doing a structured clone. That doesn't feel better to me? Well, the hope is that Cu.cloneInto is faster than JSON.stringify. That needs to be proved, of course. Alternatively, I have a (quite hackish) idea to lock things until we have finished cloning asynchronously. > > Certainly, the largest win is yield just after "// Collection is complete. > > We may now be safely interrupted." in `_saveState`. This additional cut is > > basically because it's free. > > It doesn't feel free to me judging by how much code we have to touch for > that. Looks more complicated too. Well, the big change is putting everything in a `Task.spawn`.

Tim Taubert [:ttaubert] said:
I have the same problem daily, coming out of suspend mode. I wonder whether it's an IRCCloud problem - i.e. whether it happens for Chrome, too. It might of course not be as visible due to Chrome's process separation.

James Wheare said:
We've only seen this on Firefox. There may indeed be something we can do to avoid it in Firefox, but unfortunately I haven't been able to get any useful debugging information on what's going on. More detail on where the bottleneck is, with a stacktrace would be extremely helpful.

CC: → fbraun@mozilla.com

Frederik Braun [:freddyb] said:
Will this also affect bookmarklets?

Depends on: → 1021420

CC: → kairo@kairo.at

Target Milestone: --- → mozilla32

CC: → kairo@kairo.at

Target Milestone: --- → mozilla32

depbug-517962-Status: NEW → RESOLVED

depbug-517962-Resolution: --- → DUPLICATE

CC: → georg.fritzsche@googlemail.com, jschoenick@mozilla.com

Flags: → needinfo?(jschoenick@mozilla.com)

Georg Fritzsche [:gfritzsche] said:
John, is this already resolved or duped by the ongoing e10s work?

CC: → jypenator@gmail.com

Keywords: → dev-doc-needed

Depends on: → 1022778

Depends on: → 1022934

Boris Zbarsky [:bz] said:
> I think so, since that means they'll ignore the insertion points the binding defines. And in general, it seems to me like we should decide on the interaction model of anonymous content trees and display-box:contents. I think the obvious answer is that flattened tree construction happens _before_ display-box takes effect, since the flattened tree is technically a DOM-level concept not dependent on styles at all. So insertion points need to be computed based on the parent before it's adjusted for display-box bits.