Re: Intent to unship: "storage" attribute in options for indexedDB.open()

[Johann Hofmann]

Thank you for bringing up that use case, Ryan.

I should have mentioned that I'll file bugs for all internal users of storage: 
"persistent" so that we can deal with this in the 61 cycle. As Andrew mentioned 
we don't expect any issues, and it's a priority that this change is not an 
inconvenience or causes disruption to any other team.

Thanks!

Johann

Andrew Sutherland wrote:
> QuotaManager already has a notion of "internal" origins[1] that explicitly 
> white-lists devtools' synthetic "indexeddb" fake scheme.  It's this check 
> that avoids the prompt when persistent storage is requested.
> 
> It might make sense to expand the existing logic that acts like all 
> system-principaled origins are asking for persistent storage[2] to use the 
> check as well, or at least for the IndexedDB protocol until we get to the 
> next steps for changing how QuotaManager handles persistent data.  We could 
> do this in the same commit that removes devtools' use of the storage property.
> 
> Andrew
> 
> 1: 
> https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/dom/quota/ActorsParent.cpp#5524
> 
> 2: 
> https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/dom/indexedDB/IDBFactory.cpp#681
> 
> 
> On 03/06/2018 01:18 PM, J. Ryan Stinnett wrote:
>> DevTools is one chrome caller that might be impacted. We craft a custom
>> principal and pass `storage: persistent`[1] when using IndexedDB in the
>> tools.
>>
>> DevTools uses this storage for developer settings that should be retained
>> over time. It sounds like with the proposed change here, DevTools storage
>> might lose the persistent status. If that's true, what's the right approach
>> to maintain the status quo? I don't think it makes sense to show a
>> permission prompt when DevTools access its storage, since it is a browser
>> feature.
>>
>> Should we add an exception for the DevTools iDB principal? Should DevTools
>> use the system principal and migrate existing data?
>>
>> [1]:
>> https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/devtools/shared/indexed-db.js#34
>>
>> - Ryan
>>
>> On Tue, Mar 6, 2018 at 9:58 AM, Johann Hofmann  wrote:
>>
>>> I would like to unship the proprietary "storage" attribute in
>>> indexedDB.open()[0]. It allows developers to prevent their indexedDB
>>> storage from being evicted as part of quota management[1]. However,
>>> there is a web standard which specifies a better persistent storage
>>> mechanism and has broader vendor support[2].
>>>
>>> There are several issues with the old proprietary version:
>>>
>>> - It's only supported by Firefox.
>>> - It can be used over insecure HTTP, which is against the persistent
>>> storage spec.
>>> - Its internal mechanism is only concerned with indexedDB and does not
>>> integrate with other quota managed storage.
>>> - We actually need to maintain two separate permissions that do more or
>>> less the same thing ("indexedDB" and "persistent-storage"). The UI for
>>> managing these looks almost exactly the same and it's impossible to
>>> clarify the difference. It's a pretty annoying security/privacy UX issue
>>> and difficult to justify to users.
>>>
>>> The plan is to ignore the "storage" attribute and label all databases
>>> opened from iDB.open as default (i.e. dependent on the persistent
>>> storage mechanism).
>>>
>>> Before doing this, we will issue a deprecation warning in the browser
>>> console and write a blog post on Mozilla Hacks. Affected websites could
>>> lose their indexedDB data (equivalent to the user clearing their
>>> cookies), unless they migrate to the new storage model.
>>>
>>> We are tracking this work in bug 1354500
>>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1354500).
>>>
>>> We have seen very low usage on beta[3], with the exception of a spike in
>>> November which we attribute to about:home usage from a/b testing. After
>>> we stopped counting usage from about: pages on Nightly, the telemetry
>>> probe stopped signaling completely[4].
>>>
>>> I personally consider these numbers (prior to any evangelism or console
>>> warnings) low enough to unship within the Firefox 62 timeframe, without
>>> migration.
>>>
>>> Chrome callers should not be affected by this, since we upgrade the
>>> system principal to persistent storage automatically.
>>>
>>> Please let me know what you think.
>>>
>>> Thanks,
>>>
>>> Johann
>>>
>>> [0] https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/
>>> open#Syntax
>>> [1]
>>> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_
>>> API/Browser_storage_limits_and_eviction_criteria
>>> [2] https://storage.spec.whatwg.org/
>>> [3] https://mzl.la/2GVyQ7g
>>> [4] https://mzl.la/2FqW0FH
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>> ___
>> dev-platform mailing list
>> dev-pla

QA Firefox 61 feature testing pi-requests deadline is March 13

[Tom Grabowski]

Hi,

Similar to what QA did for previous Firefox feature testing prioritization
,
we would like to do the same for Fx61. In order to help with the
process, *please
submit your pi-request
 by March 13. *This is
needed to assure QA will be involved in your feature development work for
the next Nightly 61 cycle.


*Q: What happens after the deadline?*
A: After the deadline QA will come back with a prioritized list of work
that represents what we are committing to for the next cycle. We want to
ensure this list matches eng and product expectations.

*Q: What if I miss the deadline?*
A: We reserve the right to say that we can't pick up work for late requests
in the current cycle. You can still develop and execute your own test plan
or defer the work to the following cycle.

*Q: What about unknown or unexpected requests? What if there is a business
reason for a late request? What do we do with experiments and System
Add-ons?*
A: In order to remain flexible, we will keep some percentage of time open
for requests like these.

*Q: There's no way I'm going to remember to do this. *
A: Do it now! I'll also send out a reminder next week.

Thanks,
Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: skip-if(verify)

[Gabriele Svelto]

I've also seen TV failures caused by flaws in the test harness which
weren't visible before. See bug 1410165 [1] for example, it was caused
by an observer being unregistered after the first iteration of a test
had finished, causing the following iterations to fail.

 Gabriele

[1] Permaorange test-verify
dom/plugins/test/mochitest/test_crash_notify.xul |
expected-crash-dump-missing - This test did not leave any crash dumps
behind, but we were expecting some!
https://bugzilla.mozilla.org/show_bug.cgi?id=1410165

On 06/03/18 20:05, Kyle Machulis wrote:
> In my experience, many tests were written pre-test-verify, and don't clean
> up correctly to deal with multiple runs in the same process. They work fine
> when running as a single session, but blow up in TV. Having skip-if(verify)
> means that we can at least mark those tests as known broken on TV without
> taking them out of the test suites completely, especially if we find them
> in places that we don't know how to fix them and need to file to someone
> else who may not currently have time to fix.
> 
> On Tue, Mar 6, 2018 at 10:49 AM, Emilio Cobos Álvarez 
> wrote:
> 
>> On 03/06/2018 06:04 PM, Geoffrey Brown wrote:
>>> It is now possible to skip tests in test-verify. Simplify annotate the
>>> manifest for your test:
>>>
>>> [test]
>>> skip-if = verify
>>>
>>> or, for reftests:
>>>
>>> skip-if(verify) ...
>>>
>>> and the test-verify (TV) test task will not try to verify the annotated
>>> test.
>>>
>>> Please don't abuse this feature! Most TV failures indicate a weakness in
>>> the test.
>>
>> Could you point to an example of a "good" use of this feature? Is it
>> just to avoid TV failing too intermittently? Is TV unable to run some
>> tests? When does TV provide no value?
>>
>> Thanks!
>>
>>  -- Emilio
>> ___
>> 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
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Prefs overhaul

[Kris Maglione]

On Wed, Mar 07, 2018 at 02:08:59PM +1100, Nicholas Nethercote wrote:

Hi,

I've been doing a lot of work to improve libpref recently, and there is
more in the pipeline. I've written a brief roadmap that might be of
interest to people: https://wiki.mozilla.org/Platform/PrefsOverhaul

I'd be happy to hear feedback, via this list or other means. Thanks.


Related to this (and particularly in the light of bug 1425613), 
I've been thinking it's about time to migrate the preference 
service bindings to WebIDL, and kill the XPIDL/XPCOM bindings 
altogether.


The XPC overhead on the JS side is pretty bad given how much we 
use the service, and a WebIDL implementation would make it 
easier to add certain optimizations (like native lazy pref 
getters) on top of the ones we'd automatically get from the 
conversion.


From the native side, accessing the pref service via 
do_GetService adds a bunch of get service overhead, and then a 
bunch of virtual call overhead for each method call. We do have 
already have a non-virtual API. We should just make that the 
only option.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform