Filters:
Languages
Toughness
Just bugs labeled...
Expand all
Collapse all
-
· link
As a first step for bug 872980, we should deprecate any attempt to store more than 16kb of preferences in a field (or possibly in a non-root branch) and print a warning whenever code attempts to do this.
-
· link
When we toggle from light to dark to auto, the fade transition is a little choppy. Can we smooth it out a bit, and make it a little faster (roughly 30%) while we're at it?
-
Transitions were unprefixed in Fx16: https://developer.mozilla.org/en-US/docs/Web/CSS/transition#Browser_compatibility Let's update our CSS accordingly.
-
Transitions were unprefixed in Fx16: https://developer.mozilla.org/en-US/docs/Web/CSS/transition#Browser_compatibility Let's update our CSS accordingly.
-
The function str_match(), implementing the .match() property of string objects, should be converted to use the new MatchOnly regular expression mode from Bug 808245, with lazy updating of the RegExpStatics. This change is motivated by Bug 792797 (affects loading time of certain blogspot.com domains). str_match() is implemented in terms of a helper function DoMatch(). When a global regular expression is given as the .match() argument, DoMatch() is supposed to continuously run the regular expression until it ceases to match, then accumulate the results into an array. However, in the current implementation, if the global array contains N parentheses (capturing subexpressions), DoMatch() will generate a temporary match results array of size N+1, copy this array into the RegExpStatics, then discard the last N elements and append only the first to the results array. This is a large waste of effort, especially if there is a tremendous number of parentheses as is the case with blogspot. Instead, we should use MatchOnly mode via .executeMatchOnly(), which will ignore subexpressions and only capture the first match. The RegExpStatics will then be lazily updated at the end of execution with the inputs to the last successful match. For cleanliness, it would be preferable to implement str_match() without referring to DoMatch() -- then only str_replace() depends on it, and we can rename it, simplify it, and possibly later, remove it. This should be a fairly simple, mostly mechanical change with large performance impact given the right inputs.
-
The function str_match(), implementing the .match() property of string objects, should be converted to use the new MatchOnly regular expression mode from Bug 808245, with lazy updating of the RegExpStatics. This change is motivated by Bug 792797 (affects loading time of certain blogspot.com domains). str_match() is implemented in terms of a helper function DoMatch(). When a global regular expression is given as the .match() argument, DoMatch() is supposed to continuously run the regular expression until it ceases to match, then accumulate the results into an array. However, in the current implementation, if the global array contains N parentheses (capturing subexpressions), DoMatch() will generate a temporary match results array of size N+1, copy this array into the RegExpStatics, then discard the last N elements and append only the first to the results array. This is a large waste of effort, especially if there is a tremendous number of parentheses as is the case with blogspot. Instead, we should use MatchOnly mode via .executeMatchOnly(), which will ignore subexpressions and only capture the first match. The RegExpStatics will then be lazily updated at the end of execution with the inputs to the last successful match. For cleanliness, it would be preferable to implement str_match() without referring to DoMatch() -- then only str_replace() depends on it, and we can rename it, simplify it, and possibly later, remove it. This should be a fairly simple, mostly mechanical change with large performance impact given the right inputs.
-
· link
The extension draft is here: http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/ An overview of how WebGL extensions are added is here: https://wiki.mozilla.org/Platform/GFX/WebGL/Contribute/Extensions OES_texture_float was implemented in bug 630672, and should be very similar to what is needed here.
-
a plain mapping into internal relation (node_parent_of)
-
· link
Under certain conditions, the Firefox cache is not fully cleared when requested by the user. This has minor security implications as it provides a means to track a client across connections despite them supposedly having cleared their entire cache state. Steps to reproduce: 1. Create a file with following HTML: <audio autoplay> <source type="audio/ogg" src="https://www.gstatic.com/youtube/media/harlem-shake.ogg"> </audio> 2. When the audio plays, the URL appears in ABP's blockable items list, in the LiveHTTPHeaders sidebar, in the Firefox Web Console, can be handled by proxy plugins, and can be observed by network traffic tools. Good. 3. Use Tools -> Clear Recent History. Select "Everything" as the time range and check all boxes. 4. Refresh the HTML file, possibly even using Ctrl+F5. 5. The URL does not appear in ABP's blockable items list, and is not observed in any of the other places. No traffic is sent over the network. about:cache states that the cache is totally empty. The audio is mysteriously playing anyway.
-
· link
Under certain conditions, the Firefox cache is not fully cleared when requested by the user. This has minor security implications as it provides a means to track a client across connections despite them supposedly having cleared their entire cache state. Steps to reproduce: 1. Create a file with following HTML: <audio autoplay> <source type="audio/ogg" src="https://www.gstatic.com/youtube/media/harlem-shake.ogg"> </audio> 2. When the audio plays, the URL appears in ABP's blockable items list, in the LiveHTTPHeaders sidebar, in the Firefox Web Console, can be handled by proxy plugins, and can be observed by network traffic tools. Good. 3. Use Tools -> Clear Recent History. Select "Everything" as the time range and check all boxes. 4. Refresh the HTML file, possibly even using Ctrl+F5. 5. The URL does not appear in ABP's blockable items list, and is not observed in any of the other places. No traffic is sent over the network. about:cache states that the cache is totally empty. The audio is mysteriously playing anyway.
