HTTP/2 and User-Agent strings?
Firefox, Chrome, and IE only support HTTP/2 over TLS, even though the spec does not require it. What if browser vendors similarly agreed to never send the User-Agent header over HTTP/2? If legacy content relies on User-Agent checks, it could: * Stick with HTTP/1.1. * Use HTTP/2 connection upgrade from HTTP/1.1, grabbing the User-Agent header on the initial HTTP/1.1 connection. * Check navigator.userAgent on the client. If we can't kill the User-Agent header at this juncture, then when? :) btw, here is the spartan User-Agent string for Microsoft's new Spartan browser: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0 (Conspicuously missing: any mention of MSIE or Trident.) chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On 1/27/15 9:29 AM, Jonas Sicking wrote: We keep telling websites to not use the UA string, however we've so far been very bad at asking them why they use the UA string and then create better alternatives for them. Essentially many websites need to do server-side feature detection in order to determine what version of the website to serve. However we expose *very* few client capabilities in the original HTTP request to a website. Essentially only supports HTML, which clearly isn't terribly useful. Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On 27/01/2015 21:31, Chris Peterson wrote: On 1/27/15 9:29 AM, Jonas Sicking wrote: We keep telling websites to not use the UA string, however we've so far been very bad at asking them why they use the UA string and then create better alternatives for them. Essentially many websites need to do server-side feature detection in order to determine what version of the website to serve. However we expose *very* few client capabilities in the original HTTP request to a website. Essentially only supports HTML, which clearly isn't terribly useful. Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. Not so much studies as you could look at what people actually do with this, see e.g.: http://wurfl.sourceforge.net/help_doc.php which goes down to what media formats devices play, what types of OMA DRM they support, whether they support pdf, are a smart tv, etc. etc. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On 1/27/15 9:29 AM, Martin Thomson wrote: On Tue, Jan 27, 2015 at 2:51 AM, Daniel Stenberg dan...@haxx.se wrote: I personally think it would be wrong to do it in connection with HTTP/2 since it'll bring a bunch of unrelated breakage to be associated with the protocol bump. I'd rather we didn't for similar reasons. That's a good point. We don't want to hamper HTTP/2 adoption because of an unrelated compatibility change. However, one could make a similar argument about Firefox and Chrome (and, for the time being, IE) tying HTTP/2 with TLS. If we're interested in this, maybe run an experiment where Nightly offers a User-Agent of just Nightly. See how that goes. I don't expect much success unfortunately; UA detection is still in pretty wide use, and not always for the wrong reasons (you won't have to search back far on mozilla-google-discuss for an example). I have used Nightly without any User-Agent header (using the Modify Headers add-on) for about a month. I have not found any major problems, but I'm sure they exist. :) chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
Chris, Le 28 janv. 2015 à 06:31, Chris Peterson cpeter...@mozilla.com a écrit : Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. We did ask. The range of reasons spreads on a very large spectrum. Technical, Commercial, Laziness, Economic constraints, etc. During the survey last year, we got answers from business people, Web developers, companies providing UA dbs, etc. The answers are summarized in this article: http://www.otsukare.info/2014/03/31/ua-detection-use-cases Below an extract of the use cases list: Device/Software capabilities • Send anterior version of a browser to a simpler version of the Web site. The new Web site using technologies unsupported on old browsers, the user will get a bad experience. • Block the access to an anterior version of browser and recommend the user to download a new version of the browser. • Redirect the browser to the (feature phone|smartphone|tablet|desktop|tv|wearable) Web site or provide directly content optimized for the device. • Customizing content such as the choice of video formats, the UI elements size, Ads. • Plugin and framework supports such as J2ME, DRM. • Device own material performance Network Performances • Server-side optimization of media (size and formats). Certain devices type are believed to access the Web through a type of connection. The assumption is often triggered by if it's a mobile the network bandwidth and/or latency is either bad or expensive. Technical • Blocking some abusive bots • A/B testing during feature deployments • Fallback: Once features detection has failed to be able to customize the user experience: Incomplete support of features, support not optimized for a specific feature, misleading user agent with regards to support Business • Delivering specific content (Premium, documentation, help) for certain devices • Native app: Encouraging to download the platform native app for capturing an audience • Upgrading the user agent: Proposing the right software to download when upgrading • Analytics and statistics reporting -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
Chris, Le 28 janv. 2015 à 06:19, Chris Peterson cpeter...@mozilla.com a écrit : I have used Nightly without any User-Agent header (using the Modify Headers add-on) for about a month. I have not found any major problems, but I'm sure they exist. :) I have used for a while the User-Agent: FuckYeah/1.0 header for the same reasons. It breaks thing on the desktop time to time, but do not make the Web that unusable. The issue on the other hand becomes a lot stronger on mobile. Most of the time you will receive the desktop site instead of the mobile site. And most of the time, People are sending a content/CSS/JS which is tailored for a specific rendering engine. Some Google properties for example do that and basically you never receive the tier1 if you have the wrong UA. Sometimes you will just be blocked. Another issue you will encounter is that the Web is a legacy content factory. Sites disappear a lot (unfortunately), but there is a mass of them which never gets updated including their bugs or bad habits. Some sites will not work without a proper UA. The unfortunate issue is that most people don't think the site is badly implemented, they think the browser is crap because it is not working. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
mozregression updates
So I already blogged about this on planet mozilla, but I figured it would probably also be worth mentioning here that a lot of work has gone into mozregression (a tool for automatically determining when a regression was introduced into Firefox by bisecting builds on ftp.mozilla.org) over the past few months: http://wrla.ch/blog/2015/01/mozregression-updates/ If it's been a while since you've last upgraded mozregression, I encourage you to do so. There have been many fixes and improvements to make the tool more useful and reliable. Will ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On Tue, Jan 27, 2015 at 1:31 PM, Chris Peterson cpeter...@mozilla.com wrote: On 1/27/15 9:29 AM, Jonas Sicking wrote: We keep telling websites to not use the UA string, however we've so far been very bad at asking them why they use the UA string and then create better alternatives for them. Essentially many websites need to do server-side feature detection in order to determine what version of the website to serve. However we expose *very* few client capabilities in the original HTTP request to a website. Essentially only supports HTML, which clearly isn't terribly useful. Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. The WURFL database is very popular. So most likely it carries the data that most websites need. Sadly it also carries a lot of other, likely unused data. Like if the browser supports iframes and/or javascript. I've heard that screen size as well as video decoding capabilities (not just ability to decode, but the ability to do so at a good framerate) have been requested for FirefoxOS partners. I've tried to reach out to facebook and a couple of other sites to find out what information that they use. However I didn't get any definitive answers and haven't had the bandwidth to hunt them down for a real answer. Definitely something that would be great if someone wanted to take on. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On Tue, 27 Jan 2015, Chris Peterson wrote: Firefox, Chrome, and IE only support HTTP/2 over TLS, even though the spec does not require it. THe IE people have stated repeatedly that they will support it over plain TCP eventually though, it was just not done in the preview. What if browser vendors similarly agreed to never send the User-Agent header over HTTP/2? Why would browsers agree to do that and if they/we do, why would it be limited to HTTP/2 ? I personally think it would be wrong to do it in connection with HTTP/2 since it'll bring a bunch of unrelated breakage to be associated with the protocol bump. -- / daniel.haxx.se ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
On Wed, Jan 28, 2015 at 3:18 PM, Seth Fowler s...@mozilla.com wrote: Sounds good! +1 from me. Bike shedding: - Make Range() and ReverseRange() templates, so you can use them with any type that supports the appropriate operators. This also implies removing ‘Integer’ from their names, I think. I wanted to use this name as well, but there is one problem that we have had mozilla::Range template in MFBT, which is for pointers. I guess we probably can rename it to something like PointerRange. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
On Wed, Jan 28, 2015 at 1:18 PM, Seth Fowler s...@mozilla.com wrote: Sounds good! +1 from me. Bike shedding: - Make Range() and ReverseRange() templates, so you can use them with any type that supports the appropriate operators. This also implies removing ‘Integer’ from their names, I think. - It’d be nice to add a constructor that supports specifying both the beginning and the end points, and another constructor that further supports specifying a stride. YAGNI*. Someone can implement those once they need them. - Kyle * You aren't gonna need it ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: KeyboardEvent.code attribute
DOM Level 3 Events (D3E) defines an attribute of KeyboardEvent, .code, it allows web applications to check physical key. The specs are: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#code-motivation https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html The value of .code doesn't depend on selected keyboard layout nor modifier state. The last blocker bug is support of Sun keyboard's legacy keys (We know some Linux users are still using Sun keyboard). https://bugzilla.mozilla.org/show_bug.cgi?id=1020139 Today, this is defined by the newest WD of D3E. Therefore, I'm working on this now. After that, I'd like to enable KeyboardEvent.code in release build too (In non-release builds, already enabled since May, 2014). If we enable this, Gecko is the first engine to support this. Bug to turn on by default in release build: https://bugzilla.mozilla.org/show_bug.cgi?id=1126673 -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PL_DHashTableLookup() is dead; long live PL_DHashTableSearch()
Hi,
I just landed on mozilla-inbound the patches for
https://bugzilla.mozilla.org/show_bug.cgi?id=1124973, which replaced
PL_DHashTableLookup() with PL_DHashTableSearch().
(If you haven't heard of PL_DHashTableLookup(), that's because it is
quite new. https://bugzilla.mozilla.org/show_bug.cgi?id=1118024 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1120262 replaced
PL_DHashTableOperate() with PL_DHashTable{Lookup,Add,Remove}).
PL_DHashTableLookup() was a strange API. You might expect it to return
a pointer to an entry on success and null on failure. Instead it would
always return a non-null hash table entry, and you then had to use
PL_DHASH_ENTRY_IS_FREE or PL_DHASH_ENTRY_IS_BUSY to test whether the
entry was in use. In fact, a few callers failed to do the right thing
and instead *did* do (useless) null checks and the fact that they
mostly worked was more by luck than design.
PL_DHashTableSearch() provides the abovementioned, obvious interface.
The bug's patches also removed PL_DHASH_ENTRY_IS_{FREE,BUSY} from
pldhash.h, because they are no longer needed by users of PLDHashTable.
I haven't prepared patches for comm-central but there are only a
handful of places that need changing and they should be very simple to
change.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript code coverage
I thought someone did experiments with the Debugger API and concluded that using it to capture code coverage was too slow to be practical: we need something built into the engine that is fast. Also, part of the Engineering Operations Strategic Plan is to provide better data and metrics (including code coverage). Speaking as a member of that organization, I'd love to deliver JavaScript code coverage. I'm pretty sure we need the SpiderMonkey Team to step up and implement something. On Tue, Jan 20, 2015 at 1:30 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: I recommend reading https://developer.mozilla.org/en-US/docs/Tools/Debugger-API or js/src/doc/Debugger/ for more information. On Tue, Jan 20, 2015 at 1:29 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: On Mon, Jan 19, 2015 at 12:36 PM, Joshua Cranmer [image: ] pidgeo...@gmail.com wrote: Getting good code coverage (line and branch coverage) ultimately requires fine-grained instrumentation (ideally bytecode-level) not presented by the current Debugger. I think you can get fine-grained enough data with the existing Debugger API by doing the following: * Adding all existing globals as debuggees: `Debugger.prototype. addAllGlobalsAsDebuggees` * Adding new globals as debuggees: have your Debugger's onNewGlobal hook to always add the new global as a debuggee. * For each `Debugger.Script` (on initialization via `Debugger.prototype.findScripts` and on new scripts in the future via the `onNewScript` hook): *** Use `Debugger.Script.prototype.getAllOffsets` to get all byte code offsets which are entry points to each line in the script *** Set a breakpoint on each of those offsets which, when hit, records that the offset's line was executed ___ 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: HTTP/2 and User-Agent strings?
On Tue, Jan 27, 2015 at 1:16 AM, Chris Peterson cpeter...@mozilla.com wrote: Firefox, Chrome, and IE only support HTTP/2 over TLS, even though the spec does not require it. What if browser vendors similarly agreed to never send the User-Agent header over HTTP/2? If legacy content relies on User-Agent checks, it could: * Stick with HTTP/1.1. * Use HTTP/2 connection upgrade from HTTP/1.1, grabbing the User-Agent header on the initial HTTP/1.1 connection. * Check navigator.userAgent on the client. If we can't kill the User-Agent header at this juncture, then when? :) There's still too many actually useful things that websites use the UA-string for, and for which we don't have a replacement. We keep telling websites to not use the UA string, however we've so far been very bad at asking them why they use the UA string and then create better alternatives for them. Essentially many websites need to do server-side feature detection in order to determine what version of the website to serve. However we expose *very* few client capabilities in the original HTTP request to a website. Essentially only supports HTML, which clearly isn't terribly useful. We do also send some information related to the actual network connection (like http/2 support and content-encoding support), but that's not helping the server detect what the browser can do once content has been received. The result is that servers detect client capabilities by trying to identify the UA and then look up capabilities in a server-side database. So no, I don't think that we can get rid of the UA-string. At least until we provide other information to the server about client side capabilities. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On Tue, Jan 27, 2015 at 2:51 AM, Daniel Stenberg dan...@haxx.se wrote: I personally think it would be wrong to do it in connection with HTTP/2 since it'll bring a bunch of unrelated breakage to be associated with the protocol bump. I'd rather we didn't for similar reasons. If we're interested in this, maybe run an experiment where Nightly offers a User-Agent of just Nightly. See how that goes. I don't expect much success unfortunately; UA detection is still in pretty wide use, and not always for the wrong reasons (you won't have to search back far on mozilla-google-discuss for an example). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
Sounds good! +1 from me.
Bike shedding:
- Make Range() and ReverseRange() templates, so you can use them with any type
that supports the appropriate operators. This also implies removing ‘Integer’
from their names, I think.
- It’d be nice to add a constructor that supports specifying both the beginning
and the end points, and another constructor that further supports specifying a
stride.
- Seth
On Jan 27, 2015, at 6:24 PM, Xidorn Quan quanxunz...@gmail.com wrote:
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
tbsaunde uint32_t count = array.Length(); for (uint32_t i = length - 1; i
length; i--)
smaug iterate from length() to 1 and index using i - 1
jcranmer for (uint32_t i = array.Length(); i-- 0; ) { }
tbsaunde's method should work fine, but not intuitive. smaug's looks fine
to me, but could cause some problem if I use i instead of i-1 by mistake.
jcranmer's... I don't think it is a good idea, anyway. None of them looks
prefect to me.
As we have supported range-based for loop in our code, I purpose that we
have something like ReverseIntegerRange, and use this with range-based loop
to iterate the index. So we can use, for example: for (auto i :
ReverseIntegerRange(array.Length()))
Maybe we can also add IntegerRange to benefit from the integer type
dedution.
How does it sound?
- Xidorn
___
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
Reversely iterating nsTArray
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
tbsaunde uint32_t count = array.Length(); for (uint32_t i = length - 1; i
length; i--)
smaug iterate from length() to 1 and index using i - 1
jcranmer for (uint32_t i = array.Length(); i-- 0; ) { }
tbsaunde's method should work fine, but not intuitive. smaug's looks fine
to me, but could cause some problem if I use i instead of i-1 by mistake.
jcranmer's... I don't think it is a good idea, anyway. None of them looks
prefect to me.
As we have supported range-based for loop in our code, I purpose that we
have something like ReverseIntegerRange, and use this with range-based loop
to iterate the index. So we can use, for example: for (auto i :
ReverseIntegerRange(array.Length()))
Maybe we can also add IntegerRange to benefit from the integer type
dedution.
How does it sound?
- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On 28/01/2015 01:29, Martin Thomson wrote: On Tue, Jan 27, 2015 at 2:51 AM, Daniel Stenberg dan...@haxx.se wrote: I personally think it would be wrong to do it in connection with HTTP/2 since it'll bring a bunch of unrelated breakage to be associated with the protocol bump. I'd rather we didn't for similar reasons. If we're interested in this, maybe run an experiment where Nightly offers a User-Agent of just Nightly. See how that goes. I don't expect much success unfortunately; UA detection is still in pretty wide use, and not always for the wrong reasons (you won't have to search back far on mozilla-google-discuss for an example). Pale Moon tried to do something similar. It was rather impressive how much of the web breaks when you do that. That change was backed out in haste. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
