Re: Busy indicator API
On Mon, Jul 6, 2015 at 3:22 AM, Mike Connor mcon...@mozilla.com wrote: Anne, I assume the point is not to draw attention to background tabs. There are much more useful ways to do that, if they're going to ask for a new API/UI. Instead, my read is that they're looking for a hopefully-not-janky busy indicator for something is actually happening similar to how network indicators imply context on mobile OSes. Given that assumption, I would argue for this to be only observed in the foreground tab, as otherwise it's going to be wasteful of attention. If that's the limitation, I think this makes a ton of sense. Note that as smaug pointed out in https://github.com/whatwg/fetch/issues/19#issuecomment-118651871 you can trivially polyfill this Gecko to get the spinning behavior, including for background tabs. Does it need to be an API, or would dispatching an event be sufficient? Something like busy and idle events would be easy to send from JS, and UAs would be free to honour or ignore based on context. I think we need something where multiple pieces of code that are not aware of each other can ask for the indicator to be present and declare they no longer need it. The GitHub thread offers various APIs that accomplish that. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: xulrunner 31, swt 4.5, ZOOM
Yes, v31. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: xulrunner 31, swt 4.5, ZOOM
Ok, I solved the issue for my case. The problem was the evaluation method: in window (normal security context, not working) or as chrome (chrome security context, working!). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Busy indicator API
On 06/07/2015 03:22 , Mike Connor wrote: Does it need to be an API, or would dispatching an event be sufficient? Something like busy and idle events would be easy to send from JS, and UAs would be free to honour or ignore based on context. On the face of it it's certainly useful: writing your own busy indicator is one of the first things you get to do when producing a Web application. If we can get this built-in, it's a win. I'm slightly worried about the possibility of actually getting it right, though. It's not uncommon for Web app above a certain level of complexity to be doing more than one thing at once. If I'm conducting two operations, and have therefore dispatched two busy events (or whatever API equivalent) I would probably expect there to have to be two idle events before the UI state returns to idle (i.e. there's a busy counter). This could possibly seem acceptable, but what happens when the app transitions to a different internal page? Today wiping the DOM is enough to remove the spinners, so no one bothers maintaining state for this, but with the API you'd have to. History.pushState() could wipe the busy flag, but that might be the wrong thing to do if a busy part of your UI stays there. Also: what does the busy indicator do in fullscreen? I'm not trying to shoot this down, just pointing at potential pitfalls to avoid adding a feature that will just largely get ignored except perhaps in the simplest cases. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fwd: mozilla::TemporaryRef is gone; please use already_AddRefed
Michael Layzell wrote: In summary, the nsRefPtr is copied into a temporary in its side of the conditional. The nullptr is cast to a struct Foo*, which is constructed into a nsRefPtr, which is bound to a temporary, and then moved around a bit between temporaries. The resulting temporary xvalue then has the raw pointer extracted from it (which uses the rvalue-reference cast call - the part which is causing the problem), which is stored locally after the temporaries are destroyed. The temporaries which are created in the conditional are then destroyed, which causes a Release(), but that is OK because there was an AddRef due to the extra copy in the nsRefPtr branch. So the ternary actually causes an unnecessary AddRef/Release pair, neat. Neat as in Can we please have a static analysis to detect this please? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
Should fixing shutdown hangs be higher priority? Starting and shutting down properly (and quickly), IMO, fall into the core quality / no compromise / we have to get this right bucket. So making it higher priority sounds aligned with the Three Pillars. And if so, should we allow features with shutdown hangs to be released? Probably depends on the feature and how frequent / severe the shutdown hangs are with it. Not sure we can make a blanket judgement right here and now about it, unless we want to go hard-line on this. On 06/07/2015 4:34 PM, Vladan D wrote: Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
On Mon, Jul 6, 2015 at 1:37 PM, Ryan VanderMeulen rya...@gmail.com wrote: On 7/6/2015 4:34 PM, Vladan D wrote: Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line Windows mochitest-bc shutdown hangs have been on of the top oranges in our automation for months now. See bug 1121145. Would be great if we could get more eyes on the problem. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform The last five logs in that bug are all hanging in QuotaClient code. I'll take a look. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
On 06/07/15 22:48, Vladan D wrote: KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's lousy UX. The crash-reporter dialog pops up a minute after the user closed Firefox That's bug 1137941, but how would that reduce shutdown hangs? -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
openDialog(DOM, ..)
Hello, Consider the method: window.openDialog(URL.xul, ...). Its final result is to opens a dialog from the content read in file URL.xul. After some web surfing, it seems not possible to programmatically define a dialog, and then open that dialog (somehow) from the main window. So, in the context of a firefox extension, is there a way to define the DOM of some dialog and to 'append' that dialog to the window (making it appear?) For example, the goal would be: let dialog = window.document.createElement(dialog); // put things in this dialog // .. // finally window.openDialogFromDOM(dialog, ...); Thanks in advance MS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Shutdown hangs are very common
Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mutations from Parser handled after DOMContentLoaded?
On Monday, July 6, 2015 at 12:48:33 PM UTC-7, smaug wrote:
I don't know what have a MO set on the document during readyState=loading
actually means.
Document has three loading states - loading, interactive, complete[0].
I'm initializing MO during loading stage, so that I have a chance to mutate
elements before it gets to interactive stage.
MutationObserver callback is called at the end of microtask, so end of
outermost script execution or end of a task in general.
I don't think that's what is happening right now. I have an extended example at
the end of this post.
And MutationObserver has nothing to do with DOMContentLoaded.
I understand that. But MO fired synchronously in document.readyState=='loading'
should compete it's callback before DOMContentLoaded I believe.
I don't see any link elements in your example
Yeah, I overminimized my testcase. Below is a better one :)
Oh, you want to ensure MutationObservers are called before some script is
executed? That is indeed still a bug, Bug 789315.
Not necessarily, although that would probably fix my problem.
I expect that if I have MO set during the time when Parser is parsing HTML,
then MO's callback should be called when the element is injected into DOM and
that means before DOMContentLoaded is called.
It just seems logical to not call DOMContentLoaded (and not fire deferred
scripts in result) until MO callback is executed on elements injected into DOM
by Parser. I believe that it's not the case right now.
The proper testcase: http://labs.braniecki.net/mo/
Around 80% of time my console looks like this:
1) mo start mo.js:3:3
2) mo onMutations mo.js:16:5
3) setting ready on the element mo.js:30:7
4) main.js starts main.js:1:1
5) Promise { state: fulfilled, value: Response }
Which seems to be the right order. 1/2/3 are synchronously launched, 3 is fired
when Parser injects link into DOM, and then DOMContentLoaded triggers execution
of deferred script in 4) and in 5) we capture link.ready as a promise.
Around 20% of time my console looks like this:
1) mo start mo.js:3:3
2) main.js starts main.js:1:1
3) undefined main.js:5:1
4) mo onMutations mo.js:16:5
5) setting ready on the element
which seems to be wrong. MutationObserver starts in 1, but then
DOMContentLoaded triggers deferred main.js in 2 before MO callback is executed.
With this behavior it seems that there's no way to ensure that deferred scripts
operate on DOM already altered by synchronously executed MO callbacks, which is
what enables us to prototype and shim DOM related API's.
Does my logic make any sense?
zb.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
On 7/6/2015 4:34 PM, Vladan D wrote: Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line Windows mochitest-bc shutdown hangs have been on of the top oranges in our automation for months now. See bug 1121145. Would be great if we could get more eyes on the problem. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's lousy UX. The crash-reporter dialog pops up a minute after the user closed Firefox On Monday, July 6, 2015 at 4:37:41 PM UTC-4, RyanVM wrote: On 7/6/2015 4:34 PM, Vladan D wrote: Background: Firefox shutdown hangs are turned into shutdown crashes by a watchdog thread [1] that forces a crash if shutdown hasn't completed within 1 minute. Thanks to the watchdog and the Windows profile unlocker [2], shutdown hangs aren't as frustrating as they used to be. However, shutdown hangs might still be causing data loss and they are indicative of potentially-serious bugs in the code. According to this graph of Firefox crash rate history, shutdown hangs (crashes) make up about one third of all browser crashes [3]: https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel I've been told shutdown hangs often don't get enough attention. Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? Notes: 1. Force Firefox crash if shutdown hangs https://bugzilla.mozilla.org/show_bug.cgi?id=1038342 2. win32 implementation of nsIProfileUnlocker https://bugzilla.mozilla.org/show_bug.cgi?id=286355 3. The graph above shows that the overall crash rate jumped up by roughly a third when the watchdog code shipped in Firefox 36. Hover over the 36 box on the blue line Windows mochitest-bc shutdown hangs have been on of the top oranges in our automation for months now. See bug 1121145. Would be great if we could get more eyes on the problem. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
On Monday, July 6, 2015 at 5:00:36 PM UTC-4, David Rajchenbach-Teller wrote: On 06/07/15 22:48, Vladan D wrote: KaiRo pointed out another reason to reduce shutdown hang rates on IRC: it's lousy UX. The crash-reporter dialog pops up a minute after the user closed Firefox That's bug 1137941, but how would that reduce shutdown hangs? I think you misunderstood, I wasn't talking about the reducing the watchdog timeout :) I was saying that shutdown hangs result in bad Crash Reporter UX, so that is one more reason to *fix* shutdown hangs, i.e. reduce the shutdown hang rate by fixing the causes of hangs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
Should fixing shutdown hangs be higher priority? And if so, should we allow features with shutdown hangs to be released? I admit to skimming over shutdown-hang signatures when looking at topcrash lists. In my experience they're often longstanding issues that are difficult to diagnose and rarely end in a successful fix. Given infinite resources, we should absolutely work on these hangs. In practice though, we always have more bugs than time, so I tend to focus my efforts on other topcrashes that we have a better chance of fixing. A possible exception is for new, never-before-seen shutdown hangs. Those are likely to be more actionable since we often have a clear regression range. I think it would be fair to consider those a blocker for the associated feature. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisions to the Job Visibility Policy
Looks good to me! On Mon, Jul 6, 2015 at 10:52 AM, Ryan VanderMeulen rvandermeu...@mozilla.com wrote: For a little over 2 years, our Job Visibility Policy has been in place to identify all the requirements necessary for a build or test suite to be visible in our infrastructure. https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy However, little has changed with the policy since TBPL was still our primary CI dashboard and buildbot our only infra capable of reporting into it. Since then, Treeherder has made it possible to have jobs reporting from various data sources and harnesses. Also, our automated testing needs have grown as new features have landed, some of which have pushed the boundaries of what falls under the existing policy. As a result, the sheriffing team has been working to update the policy to better encompass the current state of our CI infrastructure and testing needs. The latest version of the revised policy is visible below: https://wiki.mozilla.org/User:RyanVM/Job_Visibility_Policy_Updates The tl;dr: Instead of only having binary visible or hidden states, we're adding a middle ground. A Tier 2 option is being added that allows for jobs that meet most but not all of the visibility requirements to be visible by default on Treeherder, but with reduced sheriffing expectations. Treeherder already supports this mode, albeit with some bugs at the moment that are being worked on. Please take a minute to look at the revised policy and let me know of any questions/concerns that need addressing before it is finalized. I'm hoping to do so within the next few days - end of the week at the latest. Thanks, Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Busy indicator API
I think an API like: window.navigator.addBusyTask(promise); would be great. The API can be called any time and any number of times. The API would run the spinner until all provided promises are resolved. So if it's called twice with different promises, the spinner doesn't stop when one of the promises are resolved, but rather when the last promise is resolved. / Jonas On Mon, Jul 6, 2015 at 2:24 AM, Robin Berjon ro...@w3.org wrote: On 06/07/2015 03:22 , Mike Connor wrote: Does it need to be an API, or would dispatching an event be sufficient? Something like busy and idle events would be easy to send from JS, and UAs would be free to honour or ignore based on context. On the face of it it's certainly useful: writing your own busy indicator is one of the first things you get to do when producing a Web application. If we can get this built-in, it's a win. I'm slightly worried about the possibility of actually getting it right, though. It's not uncommon for Web app above a certain level of complexity to be doing more than one thing at once. If I'm conducting two operations, and have therefore dispatched two busy events (or whatever API equivalent) I would probably expect there to have to be two idle events before the UI state returns to idle (i.e. there's a busy counter). This could possibly seem acceptable, but what happens when the app transitions to a different internal page? Today wiping the DOM is enough to remove the spinners, so no one bothers maintaining state for this, but with the API you'd have to. History.pushState() could wipe the busy flag, but that might be the wrong thing to do if a busy part of your UI stays there. Also: what does the busy indicator do in fullscreen? I'm not trying to shoot this down, just pointing at potential pitfalls to avoid adding a feature that will just largely get ignored except perhaps in the simplest cases. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mutations from Parser handled after DOMContentLoaded?
On 07/06/2015 10:33 PM, Zibi Braniecki wrote: Hi all, I have a question about MO behavior. From what I understand, MutationObserver API is designed in a way that is supposed to guarantee two things that I need: 1) That if I have a MO set on the document during readyState=loading, then all consequent elements injected by Parser into DOM will go through MO before layout 2) And that they will block DOMContentLoaded I don't know what have a MO set on the document during readyState=loading actually means. MutationObserver callback is called at the end of microtask, so end of outermost script execution or end of a task in general. And MutationObserver has nothing to do with DOMContentLoaded. The first behavior is crucial for client side localization so that we can translate the node that is being injected before any frame creation/layout happens. I'm still not sure if that's the case and I'm not even sure how to test if our implementation guarantees that. But now, I have more doubts because it seems that we don't do 2). My test works like this - https://pastebin.mozilla.org/8838694 I first start a MutationObserver inline and register it on document.head. Whenever link with rel=localization is inserted I add `ready` property to it. I don't see any link elements in your example Then I run a deferred script (in my tests I use external scripts, but I inlined them for the testcase) which collects all links with rel=localization from document.head and operates on their `ready` property which should be, according to my logic, always there. When I test this, I get nondeterministic behavior with ready being set in ~80% of reloads and in 20% onAddedHeadElement is executed after the deferred script. Is that a bug? Because if it's not, it feels like it should be. Or am I wrong? Oh, you want to ensure MutationObservers are called before some script is executed? That is indeed still a bug, Bug 789315. zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fwd: mozilla::TemporaryRef is gone; please use already_AddRefed
I suppose that the general problem is that we are using an nsRefPtr lvalue in one side of the branch, and an nsRefPtr xvalue on the other (as the nullptr is being cast to an nsRefPtr, which has to live in a temporary making it an xvalue). This is reasonable in a situation where we actually want an nsRefPtr, as when the value is used somewhere, it will be moved, and we won't produce any extra addref/releases. The problem, instead, comes from the operator T*() , which allows us to extract one of these references from an xvalue. I think that every use of this conversion will frequently be a source of an unnecessary (or dangerous) addref/release pair. If we remove it, I don't think that the static analysis will be necessary, as the pattern of creating an unnecessary temporary, just to extract a value from it, should be much more visibly wrong. Foo* x = true ? nullptr : bar; would look like Foo* x = (true ? nullptr : bar).get(); which is much more obviously inefficient. On 2015-07-06 8:49 AM, Neil wrote: Michael Layzell wrote: In summary, the nsRefPtr is copied into a temporary in its side of the conditional. The nullptr is cast to a struct Foo*, which is constructed into a nsRefPtr, which is bound to a temporary, and then moved around a bit between temporaries. The resulting temporary xvalue then has the raw pointer extracted from it (which uses the rvalue-reference cast call - the part which is causing the problem), which is stored locally after the temporaries are destroyed. The temporaries which are created in the conditional are then destroyed, which causes a Release(), but that is OK because there was an AddRef due to the extra copy in the nsRefPtr branch. So the ternary actually causes an unnecessary AddRef/Release pair, neat. Neat as in Can we please have a static analysis to detect this please? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Mutations from Parser handled after DOMContentLoaded?
Hi all, I have a question about MO behavior. From what I understand, MutationObserver API is designed in a way that is supposed to guarantee two things that I need: 1) That if I have a MO set on the document during readyState=loading, then all consequent elements injected by Parser into DOM will go through MO before layout 2) And that they will block DOMContentLoaded The first behavior is crucial for client side localization so that we can translate the node that is being injected before any frame creation/layout happens. I'm still not sure if that's the case and I'm not even sure how to test if our implementation guarantees that. But now, I have more doubts because it seems that we don't do 2). My test works like this - https://pastebin.mozilla.org/8838694 I first start a MutationObserver inline and register it on document.head. Whenever link with rel=localization is inserted I add `ready` property to it. Then I run a deferred script (in my tests I use external scripts, but I inlined them for the testcase) which collects all links with rel=localization from document.head and operates on their `ready` property which should be, according to my logic, always there. When I test this, I get nondeterministic behavior with ready being set in ~80% of reloads and in 20% onAddedHeadElement is executed after the deferred script. Is that a bug? Because if it's not, it feels like it should be. Or am I wrong? zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisions to the Job Visibility Policy
On Mon, Jul 6, 2015 at 7:52 AM, Ryan VanderMeulen rvandermeu...@mozilla.com wrote: The tl;dr: Instead of only having binary visible or hidden states, we're adding a middle ground. A Tier 2 option is being added that allows for jobs that meet most but not all of the visibility requirements to be visible by default on Treeherder, but with reduced sheriffing expectations. An example of what this new tier allows might be helpful here. A few of us were talking with Ryan at Whistler about running the full Mochitest suite under Valgrind and/or TSAN. This would be slow and CPU-intensive (both tools incur a 10x+ slowdown) so we couldn't do it on every push. But we could do it, say, once or twice a day. This wouldn't meet the tier 1 requirements but it could be made to meet the tier 2 requirements. So the new, more flexible testing structure has the potential to greatly improve the coverage we get with these valuable tools. Excellent! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mutations from Parser handled after DOMContentLoaded?
We took it to the stre... IRC, and in result of that I filed to bugs: 1) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28920 2) https://bugzilla.mozilla.org/show_bug.cgi?id=1180927 zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
Vladan D. writes: Should fixing shutdown hangs be higher priority? _exit() after profile-before-change notification would be the many-holes-with-one-plug bug to prioritize. https://wiki.mozilla.org/XPCOM_Shutdown https://bugzilla.mozilla.org/show_bug.cgi?id=662444 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
On Mon, Jul 6, 2015 at 3:05 PM, Karl Tomlinson mozn...@karlt.net wrote: Vladan D. writes: Should fixing shutdown hangs be higher priority? _exit() after profile-before-change notification would be the many-holes-with-one-plug bug to prioritize. https://wiki.mozilla.org/XPCOM_Shutdown https://bugzilla.mozilla.org/show_bug.cgi?id=662444 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform I think most of our hangs are before that. The one RyanVM pointed out certainly is. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown hangs are very common
Ah, right. On 06/07/15 23:05, Vladan D wrote: I think you misunderstood, I wasn't talking about the reducing the watchdog timeout :) I was saying that shutdown hangs result in bad Crash Reporter UX, so that is one more reason to *fix* shutdown hangs, i.e. reduce the shutdown hang rate by fixing the causes of hangs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: openDialog(DOM, ..)
On 06/07/2015 17:08, Marcello Stanisci wrote: Alternatively, create an empty dialog and manipulate the dialog using DOM based on the arguments you pass using window.open[Dialog](...). This is What do you mean by 'empty dialog'? Is it a a. xul skeleton file This. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Mon, Jul 06, 2015 at 08:12:36PM -0700, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] It's not like they have widespread use in the industry either. That is, the same reasoning could be applied to them, yet, you're stopping at aFoo. Why? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I don't feel all that strongly about aFoo, but mFoo is incredibly important for reviewing code when the reviewer isn't intimately familiar with the code being changed (dom/ reviewers are a good example, because there's just too much code to know by heart). And if we accept mFoo, then the stylistic benefits of abolishing aFoo are less compelling. bholley On Mon, Jul 6, 2015 at 8:26 PM, Mike Hommey m...@glandium.org wrote: On Mon, Jul 06, 2015 at 08:12:36PM -0700, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] It's not like they have widespread use in the industry either. That is, the same reasoning could be applied to them, yet, you're stopping at aFoo. Why? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Monday 2015-07-06 23:25 -0400, Hubert Figuière wrote: On 06/07/15 11:12 PM, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. [...] I propose we strike the `aFoo` recommendation from the Mozilla style guide. I agree with this. However, if we proceed to remove this from the style guide, will we run a pass at removing the 'a' prefix or will we just let them be and have individual code change eventually clean them up? It seems likely to be hard to automate, since there will be a significant number of places where the obvious substitution (remove a and lowercase the letter following it) yields name conflicts. And I'm not sure how I'd feel about having inconsistent style for years, if we can't automate it. Do we have -Wshadow (or equivalent) enabled across the code base and insurance that the warnings get dealt with? No, we don't. I wish we did. I think it's among the more useful warnings at finding real problems, but the JS engine and some other pieces of code use a style that frequently uses shadowing. (It was on many years ago, but we turned it off due to a gcc bug (see bug 75621), C-only (not C++), that gave bogus shadowing warnings for all variables with the same names as certain global functions (|index|, etc.), that affected the JS engine in C. When the JS engine switched from C to C++, I failed to remember to turn it back on quickly, and then the JS engine, and later some other big chunks of imported code (e.g., ipc), ended up using a style that's very noisy with -Wshadow.) Nick Nethercote did a good bit of work to try to get it on, but gave up (see bug 800659). I have -Wshadow turned on in my own builds, and have continuously since we turned it off in general, and it's extremely noisy, but also spits out a number of things that point to confusing code. The noise basically means that compiler output as a whole is useless for me (errors are very difficult to find, and I never look at warnings at all), but I haven't been able to bring myself to give up completely on it. (I effectively have all warnings disabled in the hope that what I'm doing might one day help get -Wshadow turned back on, even though I never actually do anything.) It's possible that clang's -Wshadow might be easier to turn on that gcc's, though (see https://bugzilla.mozilla.org/show_bug.cgi?id=800659#c11 ). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 06/07/15 11:12 PM, Jeff Gilbert wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. [...] I propose we strike the `aFoo` recommendation from the Mozilla style guide. I agree with this. However, if we proceed to remove this from the style guide, will we run a pass at removing the 'a' prefix or will we just let them be and have individual code change eventually clean them up? Do we have -Wshadow (or equivalent) enabled across the code base and insurance that the warnings get dealt with? Cheers, Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Tue, Jul 7, 2015 at 3:26 PM, Mike Hommey m...@glandium.org wrote: The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] FWIW many coding styles do have special style for class data members. I think highlighting data members is more useful than parameters. In fact I would love to get rid of aFoo but the last time I tried, the 'a' prefix had considerable support. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I am in favor of getting rid of aFoo. -Ekr P.S. At the risk of convincing people I am crazy and thus discounting my opinion above, I rather prefer foo_ to mFoo, but this seems like more a matter of taste. On Mon, Jul 6, 2015 at 8:55 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 7, 2015 at 3:26 PM, Mike Hommey m...@glandium.org wrote: The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] FWIW many coding styles do have special style for class data members. I think highlighting data members is more useful than parameters. In fact I would love to get rid of aFoo but the last time I tried, the 'a' prefix had considerable support. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
I like 'aFoo'. Nick On Tue, Jul 7, 2015 at 1:12 PM, Jeff Gilbert jgilb...@mozilla.com wrote: I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1] As a superfluous prefix, it adds visual noise, reducing immediate readability of all function declarations and subsequent usage of the variables within the function definition. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. Notable works or style guides which *do* recommend `aFoo`: * Mozilla (except for IDL, Java, and Python) * ? 3rd-party projects in our tree which do not use `aFoo`: * Cairo * Skia * ANGLE * HarfBuzz * ICU * Chromium IPC * everything under modules/ that isn't an nsFoo.c/cpp/h * etc.? 3rd-party projects in our tree which *do* recommend `aFoo`: * ? As far as I can tell, the entire industry disagrees with us (as well as a number of our own projects), which means we should have a good reason or two for making our choice. No such reason is detailed in the style guide. I propose we strike the `aFoo` recommendation from the Mozilla style guide. - [1]: Maybe it prevents accidental shadowing? No: Either this isn't allowed by spec, or at least MSVC 2013 errors when compiling this. [2]: I do not mean this as an endorsement of the listed works and guides, but rather as illustration on how unusual our choice is. [3]: I created an Etherpad into which people are welcome to gather other works, projects, or style guides that I missed: https://etherpad.mozilla.org/6FcHs9mJYQ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: openDialog(DOM, ..)
Use a data: URL, or failing that, define your own protocol handler and use that to return the XUL DOM you want, when used with openDialog. Alternatively, create an empty dialog and manipulate the dialog using DOM based on the arguments you pass using window.open[Dialog](...). This is probably more similar to what you describe than the data: url option, but it would also mean that you initially open the dialog with different content than what you ultimately want, and that might have side-effects. ~ Gijs On 06/07/2015 15:11, Marcello Stanisci wrote: Hello, Consider the method: window.openDialog(URL.xul, ...). Its final result is to opens a dialog from the content read in file URL.xul. After some web surfing, it seems not possible to programmatically define a dialog, and then open that dialog (somehow) from the main window. So, in the context of a firefox extension, is there a way to define the DOM of some dialog and to 'append' that dialog to the window (making it appear?) For example, the goal would be: let dialog = window.document.createElement(dialog); // put things in this dialog // .. // finally window.openDialogFromDOM(dialog, ...); Thanks in advance MS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: openDialog(DOM, ..)
Alternatively, create an empty dialog and manipulate the dialog using DOM based on the arguments you pass using window.open[Dialog](...). This is What do you mean by 'empty dialog'? Is it a a. xul skeleton file or something like b. openDialog(about:blank); ? I might have missed that, but the main goal is avoiding adding a further file to the extension bundle. In case b., openDialog(about:blank) returns an HTML document that doesn't have anymore the structure of a 'dialog' xul element. So, in this case, how to get a handle to the 'dialog' element associated with about:blank ? probably more similar to what you describe than the data: url option, but it would also mean that you initially open the dialog with different content than what you ultimately want, and that might have side-effects. ~ Gijs Thanks MS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Revisions to the Job Visibility Policy
For a little over 2 years, our Job Visibility Policy has been in place to identify all the requirements necessary for a build or test suite to be visible in our infrastructure. https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy However, little has changed with the policy since TBPL was still our primary CI dashboard and buildbot our only infra capable of reporting into it. Since then, Treeherder has made it possible to have jobs reporting from various data sources and harnesses. Also, our automated testing needs have grown as new features have landed, some of which have pushed the boundaries of what falls under the existing policy. As a result, the sheriffing team has been working to update the policy to better encompass the current state of our CI infrastructure and testing needs. The latest version of the revised policy is visible below: https://wiki.mozilla.org/User:RyanVM/Job_Visibility_Policy_Updates The tl;dr: Instead of only having binary visible or hidden states, we're adding a middle ground. A Tier 2 option is being added that allows for jobs that meet most but not all of the visibility requirements to be visible by default on Treeherder, but with reduced sheriffing expectations. Treeherder already supports this mode, albeit with some bugs at the moment that are being worked on. Please take a minute to look at the revised policy and let me know of any questions/concerns that need addressing before it is finalized. I'm hoping to do so within the next few days - end of the week at the latest. Thanks, Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[Firefox Desktop] Issues found: June 29th to July 3rd
Hi everyone, You can find below the list of new issues found and filed by the Desktop Manual QA team last week (Week 27: June 29 - July 03). Additional details on the team's priorities last week, as well as the plans for the current week can be found at: https://etherpad.mozilla.org/DesktopManualQAWeeklyStatus. Release Channel: No bugs. Beta Channel: NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179222 1179222 - Mozilla Crash Reports Page incorrect displayed in Reader View Mode * Regression: No. * Severity: Normal. RESO Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179249 1179249 - Firefox no longer provides an option to make it a default .html browser * Regression: Yes - bug 1167294 https://bugzilla.mozilla.org/show_bug.cgi?id=1167294 . * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179716 1179716 - Ideal resolution not always selected for some constraints with some webcams * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1180140 1180140 - The user is unable to join back the conversation after a crash * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1180197 1180197 - [Ubuntu] The shared image freezes on the second PC during tab/window sharing * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1180222 1180222 - Both Context states (edit/no edit) visible in conversation window after participant leaves call during context editing * Regression: No. * Severity: Normal. Aurora Channel: NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179739 1179739 - Errors are thrown in the Browser Console each time the user enters Customize * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179754 1179754 - [Windows] Unable to access window controls after entering full screen * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179761 1179761 - [Windows 10] Pinning and unpinning Firefox often results in a tile missing its icon * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179763 1179763 - [Windows] Both buttons from the plug-in doorhanger can be displayed as selected at the same time * Regression: No. * Severity: Minor. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179784 1179784 - If re-joining the conversation - the chat area will be active but typing area can`t be accessed and invite/share buttons should be over video window still * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1180206 1180206 - [Win10] Unable to tell if type chat area from Standalone is in focus or not * Regression: No. * Severity: Normal. Nightly Channel: NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179234 1179234 - [OSX retina] Horizontal grey bars in the new search panel should have the same height * Regression: Yes - bug 1108648 https://bugzilla.mozilla.org/show_bug.cgi?id=1108648 . * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179752 1179752 - Awesome bar bottom margin is displayed in front of the autocomplete pop-up on Windows 10 * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179768 1179768 - Increase the URL/search bar text size on Windows 10 * Regression: No. * Severity: Normal. NEW Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1179774 1179774 - The page is incorrectly displayed when it is zoomed in/out with async scrolling feature enabled * Regression: No. * Severity: Normal. ESR Channel: No bugs. Regards, Florin. Florin Mezei | QC Team Lead SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania Email: mailto:fme...@softvision.ro fme...@softvision.ro | Web: http://www.softvision.ro/ www.softvision.ro The content of this communication is classified as SOFTVISION Confidential and Proprietary Information. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
