Re: Rethinking the crash experience
If the user has checked the Always report crashes option or equivalent, or once the user has clicked Report this crash, that sound like a good idea. On 10/07/14 02:18, Tobias B. Besemer wrote: So maybe a other option for a resolution: A msg to the user after the restart of FF that a crash-report with the ID xyz was send to Mozilla and that he can open this _Link_ to add comments, monitor the crash/bug, find workarounds, solution, ... (Would be also more flexible the doing something in the code of FF. ;-)) Tobias. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Refcounted classes should have a non-public destructor should be MOZ_FINAL where possible
Daniel Holbert wrote: (a) Your class should have an explicitly-declared non-public destructor. (should be 'private' or 'protected') Except for refcounted base classes (which as you note need to have a protected virtual destructor), is there a correct style as to whether the destructor should be private or protected and virtual or nonvirtual? First, if your class is abstract, then it shouldn't have AddRef/Release implementations to begin with. Those belong on the concrete subclasses -- not on your abstract base class. What's correct code for abstract class Foo (implementing interfaces IFoo1 and IFoo2) with derived classes Bar and Baz (implementing interfaces IBar1 and IBar2 or IBaz1 and IBaz2 respectively)? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Something like this is actually in the spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus When the user clicks the disclosure triangle, such a user agent would expand the context menu in place, to show the browser's own commands On 10/07/14 02:11, Karl Dubost wrote: Le 10 juil. 2014 à 14:57, Jonas Sicking jo...@sicking.cc a écrit : Many website use this feature to replace the UA context menu with their own context menu implemented in HTML. The result is a context menu which is less accessible. It also results in that if the user uses UA features to *not* make the UA context menu cancellable, then the UA context overlays and hides the page provided one, making it inaccessible. A suggestion from the naive-poet-department: What about something where, the main contextual menu is become a child of the developer menu. Would it be an acceptable compromise? normal system: ┌ default-item 1 ├ default-item 2 └ default-item 3 When the developer creates a contextual menu ┌ dev item 1 ├ dev item 2 ├ dev item 3 └ default-sys ├ default-item 1 ├ default-item 1 └ default-item 3 so basically, it is still available but just not deployed except if the user is hovering on default-sys. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fopen, gtest and try
On Thu, Jul 10, 2014, at 12:17 AM, Anthony Jones wrote: I've recently been using gtest for media code. However I've come across the issue of fopen() working locally but not on the try servers. https://tbpl.mozilla.org/?tree=Tryrev=11d9f94c54bd Any suggestions on how I should do this differently? I'm guessing this is a working directory issue. On Try gtest will be running as part of make check, so the cwd will be $objdir/testing/gtest: http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/testing/gtest/Makefile.in#l24 Whereas if you're doing mach gtest it looks like it doesn't change the cwd so it'll be $topsrcdir: http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/python/mozbuild/mozbuild/mach_commands.py#l616 If you run ./mach build testing/gtest/check do you get the same failures locally? We should make these consistent to avoid this problem. However, note that relying on external files is going to cause issues in the future, we should figure out exactly what we want here--we're going to eventually move gtest out of make check and into the test package, which means that we'd have to explicitly copy files that tests want to reference. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Refcounted classes should have a non-public destructor should be MOZ_FINAL where possible
On 07/10/2014 02:48 AM, Neil wrote:
Except for refcounted base classes (which as you note need to have a
protected virtual destructor), is there a correct style as to whether
the destructor should be private or protected and virtual or nonvirtual?
IMO, the destructor should be nonvirtual, since we're only expecting to
be destroyed via the concrete class's ::Release() method. So we
shouldn't need a virtual destructor. (I'm not sure how best to *ensure*
that we're never destroyed via delete pointerOfSuperclassType
though... We could give all of the superclasses protected destructors,
which would help, but not be 100% foolproof.)
As for protected vs. private -- in the concrete class, I don't think it
particularly matters, since the keywords have the same effect, as long
as the class is MOZ_FINAL.
IIRC, when I was actively working on this cleanup, if we already had an
already-existing protected section like below...
class Foo MOZ_FINAL : public Bar {
public:
[...]
protected:
// overrides of protected methods from superclass
// (in section labeled as protected for consistency w/ superclass)
[...]
};
...then I just used the existing protected area, for conciseness,
rather than adding a new private area. But if there wasn't any
consistency-with-my-superclass argument to be made for using
protected, then I'd just use private, to avoid the misleading
implication that we have subclasses which can see *our* protected stuff.
First, if your class is abstract, then it shouldn't have
AddRef/Release implementations to begin with. Those belong on the
concrete subclasses -- not on your abstract base class.
What's correct code for abstract class Foo (implementing interfaces
IFoo1 and IFoo2) with derived classes Bar and Baz (implementing
interfaces IBar1 and IBar2 or IBaz1 and IBaz2 respectively)?
Shouldn't the refcounting still be on the concrete classes? Or does that
not work for some reason? Based on your question, I'm guessing it
doesn't. Anyway, I'm not sure what's supposed to happen there. :)
~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Refcounted classes should have a non-public destructor should be MOZ_FINAL where possible
On 7/10/2014 10:46 AM, Daniel Holbert wrote: First, if your class is abstract, then it shouldn't have AddRef/Release implementations to begin with. Those belong on the concrete subclasses -- not on your abstract base class. What's correct code for abstract class Foo (implementing interfaces IFoo1 and IFoo2) with derived classes Bar and Baz (implementing interfaces IBar1 and IBar2 or IBaz1 and IBaz2 respectively)? Shouldn't the refcounting still be on the concrete classes? Why? This happens for example with nsRunnable: nsRunnable does the refcounting, and all the derivations of nsRunnable only have to worry about overriding Run because there's a virtual destructor. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
On 09/07/2014 16:48:05, Gijs Kruitbosch wrote: As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used by people when they are the assignee. There is only a lack of difference when the assignee is nob...@mozilla.org. That doesn't warrant abolishing the status (although we could arguably ask bmo folks to make the reset the assignee to default also set the status to new if the status was previously assigned) I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1036834 for resetting the status from ASSIGNED to NEW when the assignee is reset. Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Refcounted classes should have a non-public destructor should be MOZ_FINAL where possible
On 07/10/2014 08:03 AM, Benjamin Smedberg wrote: On 7/10/2014 10:46 AM, Daniel Holbert wrote: Shouldn't the refcounting still be on the concrete classes? Why? This happens for example with nsRunnable: nsRunnable does the refcounting, and all the derivations of nsRunnable only have to worry about overriding Run because there's a virtual destructor. Oh, good point -- the refcounting can go on an abstract base class, if that base class has a virtual destructor. So, I retract my if your class is abstract, then it shouldn't have AddRef/Release implementations to begin with statement from the initial email on this thread. (I think the rest of my BUT WHAT IF I NEED SUBCLASSES section from that message still applies, but just with the abstract/concrete distinction removed.) ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How did mozbuild running XPCSHELL_TESTS_MANIFESTS
2014-07-10 11:54 GMT+08:00 Nick Alexander nalexan...@mozilla.com: On 2014-07-09, 8:21 PM, Yonggang Luo wrote: In the moz.build files, there is specified XPCSHELL_TESTS_MANIFESTS, but I can not found where to processing this variable/files in mozbuild system. This one is a little tricky, because several different types of manifest are handled uniformly. The build variable is defined at [1], and the processing is mostly at [2]. Nick [1] http://mxr.mozilla.org/mozilla-central/source/python/ mozbuild/mozbuild/frontend/sandbox_symbols.py#654 [2] http://mxr.mozilla.org/mozilla-central/source/python/ mozbuild/mozbuild/frontend/emitter.py#430 Nice answer, the name mangling getting me hard to find the source where the XPCSHELL_TESTS_MANIFESTS are handled. Anyway, thanks. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Wed, 9 Jul 2014, Jonas Sicking wrote: This has been suggested many times, but the reason it's not part of the standard is that it's user-hostile. This argument always comes up, but I don't think this is an entirely accurate statement. This is less user-hostile than the web platform is today. The web platform today enables cancelling the contextmenu attribute which disables the UA context menu. That's why teh spec says: User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu. Many website use this feature to replace the UA context menu with their own context menu implemented in HTML. The result is a context menu which is less accessible. It also results in that if the user uses UA features to *not* make the UA context menu cancellable, then the UA context overlays and hides the page provided one, making it inaccessible. Right, that's why contextmenu= exists in the first place. All I'm saying is that we should strive for the ideal middle ground, where the page's context menu is given a strong presence, thus satisfying the author, but where the UA actions are still easily available. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Session Restore Experience (was Re: Reordering opened windows)
This would be my suggestion (if possible): 1. Read sessionstore.js; 2. Open first window, don't reload tabs, restore size on the right screen if multi-screen; 3. For each window in sessionstore.js, in the order in which the windows have been opened initially, trigger window opening; 4. After all windows are open, select them in the order they were last selected, last selected window as last and restore max. window if it was (on the right screen), restore min. window if it was; 5. Now restore tabs in windows in order the windows where opened last, last selected window as first, then back (maybe manage resources like CPU and bandwidth via focus); 6. Try to update the preview in the taskbar without make windows big again. This should _really_ restore the FF Session as it was before. Tobias. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
I would like to suggest chrome=hidden instead of chrome=disabled. Disabled is normally related to grayed out widgets on the web (input disabled) and not hidden elements (input type=hidden, display: none or visibility: collapse). And yes please leave some form of widget in the menu to let the user access the default menu entries even if the site have them hidden. I'm not too picky on the design for it though. // Cork - Original Me ssage - From: Ian Hickson i...@hixie.ch To: Jonas Sicking jo...@sicking.cc Cc: Dale Harvey d...@arandomurl.com, dev-platform dev-platform@lists.mozilla.org Sent: Thursday, 10 July, 2014 6:45:14 PM Subject: Re: Intent to implement: Ability to surpress default contextmenu items On Wed, 9 Jul 2014, Jonas Sicking wrote: This has been suggested many times, but the reason it's not part of the standard is that it's user-hostile. This argument always comes up, but I don't think this is an entirely accurate statement. This is less user-hostile than the web platform is today. The web platform today enables cancelling the contextmenu attribute which disables the UA context menu. That's why teh spec says: User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu. Many website use this feature to replace the UA context menu with their own context menu implemented in HTML. The result is a context menu which is less accessible. It also results in that if the user uses UA features to *not* make the UA context menu cancellable, then the UA context overlays and hides the page provided one, making it inaccessible. Right, that's why contextmenu= exists in the first place. All I'm saying is that we should strive for the ideal middle ground, where the page's context menu is given a strong presence, thus satisfying the author, but where the UA actions are still easily available. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ 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: Reordering opened windows
The update of the taskbar preview (if this is possible) should normally happen after the tabs (the first, visible one) of a window are reloaded - not all previews at the end. IMHO the SessonStore should save a Time-Stamp to each window that gets updated each time the window gets focus. This Time-Stamp reflects the history the windows had focus. On a restore the prog should always re-read this Time-Stamps. So if the user gives immediately after the session-restore have started a other window then that that have the focus before the crash the focus, then this windows have the newest Time-Stamp and gets loaded first. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Changes to B2G test symbols on TBPL
As we continue the transition from Travis to TBPL, it has been requested to use symbols for the different test suites that better-reflect the names Gaia devs are used to seeing. After discussions in bug 1013691 and on IRC with various stakeholders, the following changes are now live on TBPL: OLDNEW G - Gu (description will remain Gaia Unit Tests) Gi - Gij (description will change to Gaia JS Integration Tests) Gu - Gip (description will change to Gaia Python Integration Tests) Gb and Li will stay as-is. If you have any questions, feel free to ping me on IRC or by email. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How does xpcshell unittest are runned
I found following code in `runxpcshelltests.py`: def buildXpcsRunArgs(self): Add arguments to run the test or make it interactive. if self.interactive: self.xpcsRunArgs = [ '-e', 'print(To start the test, type |_execute_test();|.);', '-i'] else: self.xpcsRunArgs = ['-e', '_execute_test(); quit(0);'] But I don't know where does _execute_test() comes from. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does xpcshell unittest are runned
On 7/10/14, 6:54 PM, Yonggang Luo wrote: I found following code in `runxpcshelltests.py`: def buildXpcsRunArgs(self): Add arguments to run the test or make it interactive. if self.interactive: self.xpcsRunArgs = [ '-e', 'print(To start the test, type |_execute_test();|.);', '-i'] else: self.xpcsRunArgs = ['-e', '_execute_test(); quit(0);'] But I don't know where does _execute_test() comes from. testing/xpcshell/head.js is contains all the code for setting up and running each individual xpcshell test. _execute_test() lives in that file. https://hg.mozilla.org/mozilla-central/file/e1a037c085d1/testing/xpcshell/head.js#l375 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does xpcshell unittest are runned
Thanks, I found the files, but when I running unittest, I have the error code 3 for all test cases. I'd like to know what's the possible reason to cause this. On 7/10/14, 6:54 PM, Yonggang Luo wrote: I found following code in `runxpcshelltests.py`: def buildXpcsRunArgs(self): Add arguments to run the test or make it interactive. if self.interactive: self.xpcsRunArgs = [ '-e', 'print(To start the test, type |_execute_test();|.);', '-i'] else: self.xpcsRunArgs = ['-e', '_execute_test(); quit(0);'] But I don't know where does _execute_test() comes from. testing/xpcshell/head.js is contains all the code for setting up and running each individual xpcshell test. _execute_test() lives in that file. https://hg.mozilla.org/mozilla-central/file/e1a037c085d1/testing/xpcshell/head.js#l375 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
On 09/07/2014 23:48, Gijs Kruitbosch wrote: As glob noted upthread, the NEW/ASSIGNED distinction is sometimes used by people when they are the assignee. There is only a lack of difference when the assignee is nob...@mozilla.org. That doesn't warrant abolishing the status (although we could arguably ask bmo folks to make the reset the assignee to default also set the status to new if the status was previously assigned) Then there are bugs which are ASSIGNED but with multiple assignees. For example Bug 1027241 was a team effort [1]. [1] https://hg.mozilla.org/comm-central/rev/a900b3a64007 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
