What would be the right approach to hide scrollbars for one document?
For the Firefox Developer Tools, we need to be able to hide the scrollbars of
a document (in the Responsive Design Tool).
I thought that loading an stylesheet that hide the scrollbars via the new
`loadSheet` method might help.
https://hg.mozilla.org/mozilla-central/diff/4d529ec2c6ea/dom/interfaces/base/nsIDOMWindowUtils.idl#l1.34
I tried this:
```
let win = gBrowser.contentWindow;
let gIOService =
Components.classes[@mozilla.org/network/io-service;1].getService(Components.interfaces.nsIIOService);
let windowUtils =
win.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils);
let uri = gIOService.newURI('data:text/css,@namespace
url(http://www.w3.org/1999/xhtml;);@namespace xul
url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;);html
xul|scrollbar {display:none}', null, null);
windowUtils.loadSheet(uri, windowUtils.AGENT_SHEET);
```
But it doesn't appear to work.
Any idea?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Adding hardware tokens to UA string
On 24/09/12 20:06, Jason Smith wrote: 3. For v1, we probably need to still stick to the original plan for the UA that does include Android in the UA, even though that's sub-optimal to receive Android specific content. We should move to the optimal UA in long-term though without the platform identifier. Do we really think we will be able to make this shift post-v1? Surely shipping Firefox OS v1 with an Android-containing UA will simply embed the problem, as lots of sites will assume that the Firefox OS UA contains the word Android? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
(Can you hear that thud, thud, thud? It's the sound of me beating my head against my desk.) One of the intriguing things about this benchmark is that it's open source, and they're committed to changing it over time. FWIW Paul Irish agrees the sieve is a bad test, although he doesn't hate it to the extent you or i would think is deserved. https://github.com/robohornet/robohornet/issues/20#issuecomment-8837867 So maybe all hope is not lost. It's really laughable that they count the sieve as a test of handlebars.js performance. Instead of, you know, actually using handlebars.js. But I again wonder how much we can mold this into something interesting. -Justin On Tue, Sep 25, 2012 at 1:41 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Mon, Sep 24, 2012 at 5:22 PM, Tim timvk...@gmail.com wrote: So there's a new benchmark out, seemingly from google. It is designed to test performance in web app bottlenecks, especially DOM, canvas API methods, SVG. Paul Irish from Google's Chrome team is in charge of it. He blogged on it here: http://paulirish.com/2012/a-browser-benchmark-that-has-your-back-robohornet/ I'm horrified by this. Quoting my Hacker News comments (http://news.ycombinator.com/item?id=4567796): Oh god, just when web people were starting to understand how to create good benchmarks (https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus...), now we're going back to 1980s microbenchmark hell. Doesn't anyone read Hennessy and Patterson any more? The best benchmarks are real apps, not crappy little microbenchmarks that measure a single thing. (Can you hear that thud, thud, thud? It's the sound of me beating my head against my desk.) Also, one of the tests is basically a no-op executed many times (https://bugzilla.mozilla.org/show_bug.cgi?id=793913#c7). Even better, there's a prime numbers calculation test, apparently to test math. This is grimly hilarious: Hennessy and Patterson specifically cite the Sieve of Erastosthenes as an example of a toy (and thus crap) benchmark. Sigh. Daniel Buchner is apparently Mozilla's official representative on the RoboHornet committee of JavaScript experts (https://github.com/robohornet/robohornet/wiki/Committee-Membership). I don't know what his role is, but the thought of Mozilla officially blessing RoboHornet fills me with dread. While the suite may push us into some useful improvements, I worry that we'll end up implementing some stupid benchmarketing features that we will then carefully have to avoid regressing for the next 10 years. Nick ___ 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: Adding hardware tokens to UA string
3. For v1, we probably need to still stick to the original plan for the UA that does include Android in the UA, even though that's sub-optimal to receive Android specific content. We should move to the optimal UA in long-term though without the platform identifier. Do we really think we will be able to make this shift post-v1? Surely shipping Firefox OS v1 with an Android-containing UA will simply embed the problem, as lots of sites will assume that the Firefox OS UA contains the word Android? I would prefer to look at the specific problems introduced with the OS agnostic UA (drop the Android token) and, if a small subset need a workaround, use the whitelist mechanism to solve this for v1. Note that the Android token is not a silver bullet to fix the mobile Web compatibility problem. This is simply one mitigation strategy for obtaining mobile content - and, as we've seen on Firefox for Android, the Firefox for Android UA still falls very short of the mobile Web content served to the Android stock browser and iPhone. Lawrence ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
Maybe this is naive of me, but I for one don't really believe in tweaking benchmarks for the purposes of making Firefox look better. If we look bad in a benchmark, badmouthing it seems somehow more gentlemanly than stacking it. :) Anyway, I filed a bug on getting rid of the microbenchmarks, which I think we all agree is important, regardless of how that affects Firefox's score. https://github.com/robohornet/robohornet/issues/67 On Tue, Sep 25, 2012 at 10:46 AM, Daniel Buchner dbuch...@mozilla.com wrote: I've got private access to the RoboHornet repo and have been in discussions with the PM that headed that effort up, do you all want to get some code committed to help our numbers out? - Daniel On Tue, Sep 25, 2012 at 6:51 AM, Justin Lebar justin.le...@gmail.com wrote: (Can you hear that thud, thud, thud? It's the sound of me beating my head against my desk.) One of the intriguing things about this benchmark is that it's open source, and they're committed to changing it over time. FWIW Paul Irish agrees the sieve is a bad test, although he doesn't hate it to the extent you or i would think is deserved. https://github.com/robohornet/robohornet/issues/20#issuecomment-8837867 So maybe all hope is not lost. It's really laughable that they count the sieve as a test of handlebars.js performance. Instead of, you know, actually using handlebars.js. But I again wonder how much we can mold this into something interesting. -Justin On Tue, Sep 25, 2012 at 1:41 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Mon, Sep 24, 2012 at 5:22 PM, Tim timvk...@gmail.com wrote: So there's a new benchmark out, seemingly from google. It is designed to test performance in web app bottlenecks, especially DOM, canvas API methods, SVG. Paul Irish from Google's Chrome team is in charge of it. He blogged on it here: http://paulirish.com/2012/a-browser-benchmark-that-has-your-back-robohornet/ I'm horrified by this. Quoting my Hacker News comments (http://news.ycombinator.com/item?id=4567796): Oh god, just when web people were starting to understand how to create good benchmarks (https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus...), now we're going back to 1980s microbenchmark hell. Doesn't anyone read Hennessy and Patterson any more? The best benchmarks are real apps, not crappy little microbenchmarks that measure a single thing. (Can you hear that thud, thud, thud? It's the sound of me beating my head against my desk.) Also, one of the tests is basically a no-op executed many times (https://bugzilla.mozilla.org/show_bug.cgi?id=793913#c7). Even better, there's a prime numbers calculation test, apparently to test math. This is grimly hilarious: Hennessy and Patterson specifically cite the Sieve of Erastosthenes as an example of a toy (and thus crap) benchmark. Sigh. Daniel Buchner is apparently Mozilla's official representative on the RoboHornet committee of JavaScript experts (https://github.com/robohornet/robohornet/wiki/Committee-Membership). I don't know what his role is, but the thought of Mozilla officially blessing RoboHornet fills me with dread. While the suite may push us into some useful improvements, I worry that we'll end up implementing some stupid benchmarketing features that we will then carefully have to avoid regressing for the next 10 years. Nick ___ 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: What would be the right approach to hide scrollbars for one document?
Paul Rouget wrote: For the Firefox Developer Tools, we need to be able to hide the scrollbars of a document (in the Responsive Design Tool). Scrollbars are native anonymous content so most stylesheets just don't see them (the obvious exception is of course chrome://global/skin/scrollbars.css which is effectively attached explicitly to them). I believe that the easiest way to turn them off is to style the containing browser element with overflow: hidden. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
I didn't mean win, in fact I never said that. I simply meant if a test was not written well or using an API improperly/poorly that we could correct things like that. I certainly didn't mean we should game anything. Regardless, my name is off the list, and I never knew it would be used that way. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
Yeah, some were crashing that I tested (mostly canvas), but were fixed. Again, I never intended this. ***dbuc returns to woodshed :( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
Yeah, press apparently didn't distinguish between the two - and I never asked, or was placed on the Technical Adviser list. On the bright side, I never saw Firefox lagging hardcore in my testing - in fact, as this article corroborates, we can do pretty darn good on most tests, and even took the top spot on Windows 7: http://www.ghacks.net/2012/09/25/robohornet-independent-browser-benchmark/ Could it be the the Tom's Hardware numbers took a hit because they used a machine on which we were not able to utilize GPU acceleration? That would certainly tank their test runs, no? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What would be the right approach to hide scrollbars for one document?
On 9/25/12 7:54 AM, Paul Rouget wrote:
let win = gBrowser.contentWindow;
let gIOService =
Components.classes[@mozilla.org/network/io-service;1].getService(Components.interfaces.nsIIOService);
let windowUtils =
win.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils);
let uri = gIOService.newURI('data:text/css,@namespace
url(http://www.w3.org/1999/xhtml;);@namespace xul
url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;);html xul|scrollbar
{display:none}', null, null);
windowUtils.loadSheet(uri, windowUtils.AGENT_SHEET);
But it doesn't appear to work.
Any idea?
This should work for non-root scrollbars.
The problem with the root scrollbars is that they're outside the root
element's primary frame. When you add a stylesheet, we post a restyle
event on the root element. When this is processed we restyle that
element and all its descendants. But as I said, the scrollbars are
actually _siblings_ of the root element, so don't get restyled.
We could try to change this on the Gecko side, but it might be simpler
(though making the operation slightly slower) for you to just force a
root frame reconstruct. Either remove and reinsert the documentElement
or set the relevant browser to display:none, flush, and then set it
back to its normal display value
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: What would be the right approach to hide scrollbars for one document?
Boris Zbarsky wrote:
On 9/25/12 7:54 AM, Paul Rouget wrote:
let win = gBrowser.contentWindow;
let gIOService =
Components.classes[@mozilla.org/network/io-service;1].getService(Components.interfaces.nsIIOService);
let windowUtils =
win.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils);
let uri = gIOService.newURI('data:text/css,@namespace
url(http://www.w3.org/1999/xhtml;);@namespace xul
url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;);html
xul|scrollbar {display:none}', null, null);
windowUtils.loadSheet(uri, windowUtils.AGENT_SHEET);
But it doesn't appear to work.
Any idea?
This should work for non-root scrollbars.
The problem with the root scrollbars is that they're outside the
root element's primary frame. When you add a stylesheet, we post a
restyle event on the root element. When this is processed we
restyle that element and all its descendants. But as I said, the
scrollbars are actually _siblings_ of the root element, so don't get
restyled.
We could try to change this on the Gecko side, but it might be
simpler (though making the operation slightly slower) for you to
just force a root frame reconstruct. Either remove and reinsert the
documentElement or set the relevant browser to display:none,
flush, and then set it back to its normal display value
Thank you. It works: http://pastebin.mozilla.org/1842209
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
On 26/09/12 04:25, daniel...@gmail.com wrote: Yeah, press apparently didn't distinguish between the two - and I never asked, or was placed on the Technical Adviser list. No good deed goes unpunished. On the bright side, I never saw Firefox lagging hardcore in my testing - in fact, as this article corroborates, we can do pretty darn good on most tests, and even took the top spot on Windows 7: http://www.ghacks.net/2012/09/25/robohornet-independent-browser-benchmark/ Could it be the the Tom's Hardware numbers took a hit because they used a machine on which we were not able to utilize GPU acceleration? That would certainly tank their test runs, no? The ghacks.net test is using Firefox 18 nightly which includes significant performance improvements that aren't in the Firefox 15 version that Tom's Hardware is using. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
Has anyone reached out directly to the guys running the benchmark to try and get a feel for what their motivations are here? They may actually be willing to do the work necessary to make this a good benchmark. I spent an hour or two going over some of their tests and making suggestions on their github issue tracker, and someone from Google already emailed me to thank me and encourage me to contribute more directly, so it feels like they really are open to feedback and improvement here. -kg On Tue, Sep 25, 2012 at 4:21 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Tue, Sep 25, 2012 at 6:51 AM, Justin Lebar justin.le...@gmail.com wrote: One of the intriguing things about this benchmark is that it's open source, and they're committed to changing it over time. FWIW Paul Irish agrees the sieve is a bad test, although he doesn't hate it to the extent you or i would think is deserved. https://github.com/robohornet/robohornet/issues/20#issuecomment-8837867 So maybe all hope is not lost. I'm less optimistic than you are. Microbenchmarks are a completely flawed basis for a benchmark suite, so they'd have to be willing to throw away everything they currently have and completely redo it from scratch with real apps (which is *much* harder than writing microbenchmarks). But I could be wrong. Regardless, my name is off the list, and I never knew it would be used that way. Thanks, Daniel! In the meantime, I would prefer to see someone who has been involved in benchmark design to decide our position with respect to this benchmark. I've never been involved with benchmark *design*, but I've used plenty of benchmarks, the topic is a hobby-horse of mine, I've read chapter 1 of Hennessy and Patterson(!), and I've been in Mozilla's JS team long enough to know how bad benchmarks can hurt the web. I'd be happy to write an article explaining all this in some detail (I've been marshalling thoughts for such an article for the past 24 hours). The gist of the article would be good benchmarks use real apps; microbenchmarks cannot result in a good benchmark; bad benchmarks hurt the web; RobotHornet needs to be rebuilt from scratch if it is to become a good benchmark. As for whether or not that would serve as Mozilla's official response, I don't mind. I'd be happy just to post such an article on my blog and make clear that it's just my opinion if that would make people happier. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- -kg ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
On Wed, Sep 26, 2012 at 9:37 AM, Kevin Gadd kevin.g...@gmail.com wrote: Has anyone reached out directly to the guys running the benchmark to try and get a feel for what their motivations are here? They may actually be willing to do the work necessary to make this a good benchmark. Justin filed https://github.com/robohornet/robohornet/issues/67. The most relevant part of their response was this: 'I just added an answer in the FAQ about micro-benchmarks: https://github.com/robohornet/robohornet/wiki/FAQ . In summary, although these are small, succinct tests, our hope is that they don't have the failings normally associated with microbenchmarks because they are motivated by specific pain points and the tests can evolve with browsers to ensure that they continue testing what we want them to test. Of course, there are problems with the specific tests today, which we want to improve as quickly as possible now that we have good feedback on them.' It's wishful thinking, IMO. Even flawless microbenchmarks are a poor foundation for a benchmark suite. So unless they're willing to throw out everything they have and start from scratch, things won't get much better. Interestingly, Microsoft has strongly criticized RoboHornet on the exact same grounds: http://news.cnet.com/8301-1023_3-57519568-93/life-beyond-javascript-googles-abuzz-over-robohornet-test/. They created something called RoboHornet Pro, which runs RoboHornet in parallel with a weird graphical thing that looks likethe one from The Matrix. I *think* it's meant to be something of a joke; if you ignore it and just read what they've said, the message is clear, e.g.: Like all micro-benchmarks, RoboHornet is a lab test that only focuses on specific aspects of browser performance and Synthetic benchmarks are never the right choice for the customer. The RoboHornet people responded to Microsoft's comments with: Feedback like this is extremely valuable in this early alpha phase of the project, but RoboHornet aims to be an independent benchmark driven by Web developers, not a marketing tool for browser vendors. We're eager to work with people from every part of the Web ecosystem to accomplish this goal. Which doesn't sound like they're serious about making big changes. Also from that article: 'Google declined to comment, saying the project is an independent benchmark' Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Robohornet browser benchmark
On Tue, Sep 25, 2012 at 6:23 PM, Daniel Buchner dbuch...@mozilla.com wrote: I know the principal Google PM, Alex K, who heads up RoboHornet - he has been extremely helpful with our Web Components initiative. I believe he had good intentions with RoboHornet, and his personal posts (and those of Paul Irish) did not claim Google had Mozilla's official organizational support for the benchmark/tests (it was supposed to be by-devs-for-devs) Oh, absolutely. I just didn't want your presence on that list to be perceived as any kind of support from Mozilla. I read that a Microsoft person removed their name just today for the same reason. I believe Alex would be very amenable to changes to the tests, general benchmark strategy, and our contributions. I can help make sure our concerns are addressed - I'd be more than happy to do so. https://github.com/robohornet/robohornet/issues/67 has a good summary of the concerns, via comments from jlebar and I. I guess we can wait and see if they respond further. If you want to also press him privately for a response to those comments, that wouldn't hurt. If they are willing to redo things from scratch, avoiding microbenchmarks, then there's potential for a good outcome here. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
