Re: Does mozilla allow modification of Strings
On Monday, January 28, 2019 at 6:35:30 PM UTC+5:30, Emilio Cobos Álvarez wrote: > There are probably two different issues. > > On 1/28/19 1:51 PM, wrote: > > > > > > Is it possible to add an extra variable to mozilla string(nsTStringRepr). > > > > > > I added a bool variable to nsTStringRepr class in Xpcom/Strings/ > > > > While building the build I got static Assertions like below > > > > /User/Desktop/MOZB/mozilla-central/xpcom/base/nsCycleCollector.cpp:1954:3: > > error: static_assert failed "Don't create too large CCGraphBuilder objects" > > 0:34.99 static_assert(sizeof(CCGraphBuilder) <= 4096, > > If you're just experimenting this assertion can probably just be ignored > / commented out, seems it's just to prevent accidentally wasting a lot > of memory. > > > > > > > > > In normal execution (without adding any variable to core string )size of > > CCGraphBuilder is 4096 > > > > Since it is static_assert I commented that line and proceeded in > > building. > > > > Building was successful. > > > > While running firefox it just popsup and crashes. > > > > I used debbugger to know where it is getting crashed > > It is at > > > > /mozilla-central/servo/components/style/gecko/data.rs > > 75: debug_assert!(!self.inner().mContents.mRawPtr.is_null()); > > > > I guess it is getting crashed because of memory issue. I don't exactly. > > Does anyone know what is the exact problem and help me in modification of > > mozilla string. > > This one probably means that you forgot to also update the rust version > of the string representation in: > > > https://searchfox.org/mozilla-central/rev/4faab2f1b697827b93e16cb798b22b197e5235c9/xpcom/rust/nsstring/src/lib.rs#368 > > And as a result you're corrupting some memory somewhere. I think we have > unit tests that would catch that mistake: > > > https://searchfox.org/mozilla-central/rev/4faab2f1b697827b93e16cb798b22b197e5235c9/xpcom/rust/nsstring/src/lib.rs#1302 > > If you updated both, then I don't know and I'd have to take a look on a > debugger :) > > -- Emilio Thank you Emilio it worked when I updated the rust string version. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendation: Web Authentication
A W3C Proposed Recommendation is available for the membership of W3C (including Mozilla) to vote on, before it proceeds to the final stage of being a W3C Recomendation: Web Authentication https://www.w3.org/TR/webauthn/ Deadline for responses: Thursday, February 14, 2019 If there are comments you think Mozilla should send as part of the review, please say so in this thread. Ideally, such comments should link to github issues filed against the specification. (I'd note, however, that there have been previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) Given that we implement this specification, one of the editors works for us, and have been supporting this work for a while, I'm assuming we should support this advancement as well... -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: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendation: User Timing Level 2
A W3C Proposed Recommendation is available for the membership of W3C (including Mozilla) to vote on, before it proceeds to the final stage of being a W3C Recomendation: User Timing Level 2 https://www.w3.org/TR/user-timing-2/ Deadline for responses: Thursday, February 7, 2019 If there are comments you think Mozilla should send as part of the review, please say so in this thread. Ideally, such comments should link to github issues filed against the specification. (I'd note, however, that there have been previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) (I'm not sure to what extent we implement this specification. Knowing that would be helpful. If it's something we implement, then we should probably explicitly support it unless we have a good reason to do otherwise.) -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: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Secure Web Payments Interest Group
The W3C is proposing a new charter for: Secure Web Payments Interest Group https://www.w3.org/securepay/charter.html https://lists.w3.org/Archives/Public/public-new-work/2018Dec/0008.html Mozilla has the opportunity to send comments or objections through Wednesday, February 6. Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. -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: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookie policy/permission in live documents - proposal
On Monday, January 28, 2019 at 11:08:32 AM UTC-5, Ehsan Akhgari wrote: > On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz wrote: > > > On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini < > > amarches...@mozilla.com> wrote: > > > >> If we try to apply the new cookie policy immediately, 3rd party trackers > >> in opened tabs should switch to a first-party-isolation storage, but they > >> could also have already data in memory (user-tokens), and populate the new > >> cookie jar consequentially. This would break the isolation. The solution in > >> this case, is to apply the change only after the reloading. > >> > > > > That's a great point in favor of your proposal. I'm still concerned about > > "infinite-page" sites (facebook/twitter/etc) where a user typically rarely > > reloads. Would it be too ugly to apply an infobar to each active tab that > > says "The cookie policy has changed. Reload to apply the new policy > > [Reload]"? Or maybe has a [Reload this tab][Reload All] set of buttons. I > > have serious misgivings about my UX suggestion here, but maybe it will > > spark better ideas on how to communicate to users. An alert/doorhanger in > > the pref page where the setting is changed that warns the user it only > > applies to new pages and offers to reload all active tabs? > > > > One option that we have for handling this change is to modify the way we > apply the change in the Preferences UI instead of asking people to reload > their pages. For example, we can ask the user to restart their browser > when they make changes to the cookie policy/permissions (similar to how > turning permanent private browsing on/off works), or add a notice in the > Preferences saying that the changes made will only affect pages loaded from > now on, etc. > > I don't think showing a message on every open tab to ask the user to reload > it is the only UX that is possible for solving this problem, it's only one > rough idea (AFAIK nobody has talked to the UX team about it yet!)... > > Cheers, > -- > Ehsan >From a UX perspective I think your proposal makes sense, Baku. I feel that having a user manually reload each individual tab they have open is too much to ask. I spoke with Bryan Bell and we share Ehsan thinking. If a user changes preferences that affect the cookie policy they get an extra box that appears and explains they need to reload tabs in order for the new policy to apply. Did a quick mock up to show what this might look like (note the mock isn't final and the copy hasn't been reviewed) Mock can be found here: https://cl.ly/7b6cc1e85e36 Also, instead of reloading the tabs we can restart their browser as Ehsan mentioned. We'll just have to be careful and explain that all their tabs will be reopened. Is one way more performant than the other? Regards, Eric ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
