Intent to support apple-touch-icon with Browser API
Hi folks, https://bugzilla.mozilla.org/show_bug.cgi?id=921014 is tracking: support link rel="apple-touch-icon” in our browser API. With this we could start to fetch and display the "apple" format icon in FxOS or any app using browser API. There are already some opinions about we should or we shouldn’t implement it in the bug comments. This mail is to bring this topic to more people. Thanks. -- Alive C. Kuo, Firefox OS, Senior Software Engineer at Mozilla Taiwan, Taipei office. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Transition from TBPL to Treeherder
Congratulations on getting to this stage! I would like to help dogfood this, and want to know if I can trust the data parity of Treeherder and TBPL, or if that is something that you would like testing on? IOW, should I keep them both open when watching a tree / try push? Thanks! Ehsan On 2014-07-22, 9:01 PM, Jonathan Eads wrote: Hello, TBPL (https://tbpl.mozilla.org) is Mozilla’s primary tool for visualizing and analyzing automated test data. It was a huge step forward when we transitioned from Tinder Box to TBPL, and it has allowed us to push forward with new products and platforms. Many thanks to all the Mozillians who made great contributions to it! TBPL was not designed to manage the quantity or breadth of data we are working with now. The Automation and Tools team reached a point where it often takes longer to put data into TBPL than it does to set up new automation on a test device, and it should be the other way around. There are many limitations we struggle with regularly. We’ve bolted a veritable cornocopia of ad-hoc features on to TBPL to get product out the door and solve problems fast. That’s been good for supporting many projects and releases, but over time, the technical debt has backed us up against the wall. We’ve put serious mileage on TBPL, and it has earned a long and blissful retirement! We need a data reporting and analysis system that’s more sustainable, that can scale with the diverse set of automation and testing requirements of Mozilla’s broad product base, and that can keep up with our constant fast pace. The replacement we’ve been working on is called Treeherder (https://treeherder.mozilla.org). Our initial goal was to reach full feature parity with TBPL, but with a scalable and extensible data model, RESTful web service, and UI. We are planning on transitioning to it within Q3. We’ve got lots of plans for useful bells and whistles in future releases, but the first step is reaching full feature parity with TBPL. We need to make sure sheriffs and developers can carry out business as usual. So here’s some of the fun stuff that’s in this first release. Some of it may not be immediately applicable to you, but it sets the stage for lots of future goodness: * Publicly available RESTful api that supports loading data from any build system using OAuth credentials. We decoupled the buildbot-isms so we can better support jenkins, taskcluster, and whatever else comes up in the future. Among other things, this will allow us to display results for on-device tests for B2G, something that's impossible with TBPL. * The data model binds the push log to all of the build and test data permanently. This allows us to provide test data in sync with the push log to downstream consumers. It also allows us to address questions regarding build/test platform combination trends over long timelines. Expect a number of new dashboards in the near future. There’s no longer real-time dependency in the UI on the https://hg.mozilla.org/(insert favorite repo/branch)/json-pushes web service. * Integrated Talos performance data. This is not quite done yet but it will land within Q3. We can visualize and annotate Talos data inline with other test results. We hope this will allow sheriffs and developers to make better use of performance data in general. * More comprehensive platform/test filtering all throughout the application. * More UI/UX scalability. We intend to add different top-level tabs to support a variety of different dashboards and views, in addition to the standard TBPL view of the build/test universe. * More descriptive semantics to classify failures and manage annotating build/test results. The Sheriffs have given it a thorough and greatly appreciated beating and we hope that developers and anyone else using TBPL will join in and help identify as many bugs as possible over the coming weeks. We still have some bugs to work through, but we’re getting very close. We will be giving a demo and update in the Monday morning project meeting on August 4th. Jeads Background Stuff General background information and all of the treeherder bugs (thanks to edmorley!): https://wiki.mozilla.org/Auto-tools/Projects/Treeherder You can kick the tires here: https://treeherder.mozilla.org General documentation: https://treeherder-service.readthedocs.org Please file bugs here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree+Management&component=Treeherder If you have questions or concerns drop us a line in #treeherder on IRC. If you have any interest in this stuff, patches are most welcome! Take a look at the installation docs to get started https://treeherder-service.readthedocs.org/en/latest/installation.html. There are three repositories associated with Treeherder. The code for the data ingestion etl, database, and web service can be found here: https://github.com/mozilla/treeherder-service The code for the user interface
When using XUL runner to creating a chromeless window, The tag is not works under win7
I am looking for help, did anyone have the same problem for this, because my product need this feature, I need to fix this issue under win32 Also, I am interested to fix issue https://bugzilla.mozilla.org/show_bug.cgi?id=321595 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Resurrecting the Qt toolkit
I may have possible interest, to getting XUL runner works with iPhone/Android/WP So Qt is an acceptable choice. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Transition from TBPL to Treeherder
One comment: the visual distinction between a dark grey (running) and green (successful) job is much less than on TBPL. Could a very light green background and darker green border be used, similar to the orange and red boxes, to make the green jobs stand out a bit more? Another comment: compare the following TBPL and treeherder URLs: - https://tbpl.mozilla.org/?tree=Mozilla-Inbound - https://treeherder.mozilla.org/ui/#/jobs?repo=mozilla-inbound Does the 'ui/#/jobs' bit add value? Nick On Tue, Jul 22, 2014 at 6:01 PM, Jonathan Eads wrote: > Hello, > > TBPL (https://tbpl.mozilla.org) is Mozilla’s primary tool for visualizing and > analyzing automated test data. It was a huge step forward when we > transitioned from Tinder Box to TBPL, and it has allowed us to push forward > with new products and platforms. Many thanks to all the Mozillians who made > great contributions to it! > > TBPL was not designed to manage the quantity or breadth of data we are > working with now. The Automation and Tools team reached a point where it > often takes longer to put data into TBPL than it does to set up new > automation on a test device, and it should be the other way around. There are > many limitations we struggle with regularly. We’ve bolted a veritable > cornocopia of ad-hoc features on to TBPL to get product out the door and > solve problems fast. That’s been good for supporting many projects and > releases, but over time, the technical debt has backed us up against the wall. > > We’ve put serious mileage on TBPL, and it has earned a long and blissful > retirement! > > We need a data reporting and analysis system that’s more sustainable, that > can scale with the diverse set of automation and testing requirements of > Mozilla’s broad product base, and that can keep up with our constant fast > pace. > > The replacement we’ve been working on is called Treeherder > (https://treeherder.mozilla.org). Our initial goal was to reach full feature > parity with TBPL, but with a scalable and extensible data model, RESTful web > service, and UI. We are planning on transitioning to it within Q3. > > We’ve got lots of plans for useful bells and whistles in future releases, but > the first step is reaching full feature parity with TBPL. We need to make > sure sheriffs and developers can carry out business as usual. > > So here’s some of the fun stuff that’s in this first release. Some of it may > not be immediately applicable to you, but it sets the stage for lots of > future goodness: > > * Publicly available RESTful api that supports loading data from any build > system using OAuth credentials. We decoupled the buildbot-isms so we can > better support jenkins, taskcluster, and whatever else comes up in the > future. Among other things, this will allow us to display results for > on-device tests for B2G, something that's impossible with TBPL. > > * The data model binds the push log to all of the build and test data > permanently. This allows us to provide test data in sync with the push log to > downstream consumers. It also allows us to address questions regarding > build/test platform combination trends over long timelines. Expect a number > of new dashboards in the near future. There’s no longer real-time dependency > in the UI on the https://hg.mozilla.org/(insert favorite > repo/branch)/json-pushes web service. > > * Integrated Talos performance data. This is not quite done yet but it will > land within Q3. We can visualize and annotate Talos data inline with other > test results. We hope this will allow sheriffs and developers to make better > use of performance data in general. > > * More comprehensive platform/test filtering all throughout the application. > > * More UI/UX scalability. We intend to add different top-level tabs to > support a variety of different dashboards and views, in addition to the > standard TBPL view of the build/test universe. > > * More descriptive semantics to classify failures and manage annotating > build/test results. > > The Sheriffs have given it a thorough and greatly appreciated beating and we > hope that developers and anyone else using TBPL will join in and help > identify as many bugs as possible over the coming weeks. We still have some > bugs to work through, but we’re getting very close. We will be giving a demo > and update in the Monday morning project meeting on August 4th. > > Jeads > > Background Stuff > > General background information and all of the treeherder bugs (thanks to > edmorley!): > https://wiki.mozilla.org/Auto-tools/Projects/Treeherder > > You can kick the tires here: > https://treeherder.mozilla.org > > General documentation: > https://treeherder-service.readthedocs.org > > Please file bugs here: > https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree+Management&component=Treeherder > > If you have questions or concerns drop us a line in #treeherder on IRC. > > If you have any interest in this stuff
Re: Resurrecting the Qt toolkit
Wolfgang might be interested in this! On 2014-07-24, 11:21 AM, Tom Schuster wrote: Hello! I am interested in making the Qt toolkit usable again, especially on Linux. While I don't think we can ever actually use it for more platforms, except maybe some mobile devices, it is still something I care about. For that reason I am trying to avoid X11 specific code. At the moment I am mostly making sure that --enable-default-toolkit=default-qt keeps compilable. There have also been some patches to make key and mouse handling better, like shortcuts. The Qt widget uses OpenGL layers by default, which works surprisingly well. Basic layers should work on Linux, but there is some issue with expose events. The Qt widget actually at some point support almost all default widget features like filepickers, native themes and drag & drop. Oleg Romashin had to remove these features to make to code compile with Qt 5. ( https://hg.mozilla.org/mozilla-central/rev/c5953f75569b) So most of the things that are currently missing actually existed at one point and just have to be reimplemented. Right now my focus is on fixing the different kind of bounds, positions, move and resize operation on the window. After that I will probably look into native themes. There has been some discussion recently about KDE integration, which makes me hope that maybe some of them would be interested in helping out. I am actually quite new to Qt, but I find it a lot easier to handle than GTK. There seems to be also a recent shift of some apps to Qt as well. Maybe somebody is interested in this project? Here is a screenshot that I tweeted a while ago: https://pbs.twimg.com/media/BrFDppxCIAEeZr9.png:large Cheers, Tom ___ 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: Studying Lossy Image Compression Efficiency, July 2014
On Friday, July 18, 2014 10:05:19 AM UTC-5, j...@cloudflare.com wrote: > I selected 10,000 random JPEGs that we were caching for customers and ran > them through mozjpeg 2.0 via jpegtran. Some interesting facts: With mozjpeg you probably want to re-encode with cjpeg rather than jpegtran. We added support for JPEG input to cjpeg in mozjpeg to make this possible. I'm not sure, but I don't think jpegtran takes advantage of much of the work we've done to improve compression. > We will continue to work with mozjpeg 2.0 experimentally with the hope that > run time can be brought closer to what we had before as the compression looks > good. We haven't spent as much time as we'd like to on run-time optimization, we've really been focused on compression wins. We hope to spend more time on run-time performance in the future. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Studying Lossy Image Compression Efficiency, July 2014
> Are there any plans to integrate into other tools, specifically imagemagick? > > Or would you leave that up to others? For now we're going to stay focused on improving compression in mozjpeg's library. I think a larger improved toolchain for optimizing JPEGs would be great, but it's probably outside the scope of the mozjpeg project. > While you state that you now accept also jpeg for re-compression, this > usually involves loss of quality in the process. Options for improving re-compression are very limited if you're not willing to accept any quality loss. That said, our 'jpgcrush' feature does reduce size significantly for progressive JPEGs without harming quality. > Does mozjpeg have a preferred input format (for best quality/performance)? Not really. It's probably best to input JPEG if your source image is JPEG, otherwise I'd probably recommend converting to BMP for use with cjpeg. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Studying Lossy Image Compression Efficiency, July 2014
On Tuesday, July 15, 2014 3:15:13 PM UTC-5, perez@gmail.com wrote: > #1 Would it be possible to have the same algorithm that is applied to webP to > be applied to JPEG? I'm not sure. WebP was created much later than JPEGs, so I'd think/hope they're already using some equivalent to trellis quantization. > #2 There are some JPEG services that perceptually change the image, without > any noticeable artifacts. Have you tried something like that? I'm not really sure what this means, but you can experiment with re-encoding with mozjpeg and find a level that saves on file size, but at which you can't tell the difference between the source and the re-encoded image. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Resurrecting the Qt toolkit
Hello! I am interested in making the Qt toolkit usable again, especially on Linux. While I don't think we can ever actually use it for more platforms, except maybe some mobile devices, it is still something I care about. For that reason I am trying to avoid X11 specific code. At the moment I am mostly making sure that --enable-default-toolkit=default-qt keeps compilable. There have also been some patches to make key and mouse handling better, like shortcuts. The Qt widget uses OpenGL layers by default, which works surprisingly well. Basic layers should work on Linux, but there is some issue with expose events. The Qt widget actually at some point support almost all default widget features like filepickers, native themes and drag & drop. Oleg Romashin had to remove these features to make to code compile with Qt 5. ( https://hg.mozilla.org/mozilla-central/rev/c5953f75569b) So most of the things that are currently missing actually existed at one point and just have to be reimplemented. Right now my focus is on fixing the different kind of bounds, positions, move and resize operation on the window. After that I will probably look into native themes. There has been some discussion recently about KDE integration, which makes me hope that maybe some of them would be interested in helping out. I am actually quite new to Qt, but I find it a lot easier to handle than GTK. There seems to be also a recent shift of some apps to Qt as well. Maybe somebody is interested in this project? Here is a screenshot that I tweeted a while ago: https://pbs.twimg.com/media/BrFDppxCIAEeZr9.png:large Cheers, Tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
XXX PASSWORDS
Log in and pass word for sicflics ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How to setting the skin for a clean XUL application?
How to setting the skin for a clean XUL application? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Add-ons Firefox 24 crash due to recent change in JSAPI
On Thursday, October 24, 2013 9:04:13 PM UTC+5:30, Vasu Yadav wrote:
> On Thursday, September 19, 2013 10:06:30 AM UTC+5:30, Vasu Yadav wrote:
>
> > Hi
>
> >
>
> >
>
> >
>
> > We are facing problem with our Add-ons support for FireFox 24.Firefox is
> > crashing. In earlier approach we was using 'JS_GetGlobalObject' to get
> > global object from docShell.
> > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GetGlobalObject?redirectlocale=en-US&redirectslug=SpiderMonkey%2FJSAPI_Reference%2FJS_GetGlobalObject
> >
>
> >
>
> >
>
> >
>
> > As per given above link- I should use use JS_GetGlobalForObject or
> > JS_GetGlobalForScopeChain instead of JS_GetGlobalObject. I tried both of
> > them and additionally I tried GetNativeGlobal(), GetGlobalJSObject() . but
> > none of them work out. Firefox is crashing in all the cases .
>
> >
>
> >
>
> >
>
> > Could anybody help me for this issue? what are required changes need to fix
> > this problem. I have paste code for yours reference.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > bool CFFGBrowser::GetJSGlobalContextAndWindow(nsIDocShell *docShell,
> > JSContext **jsContext,
>
> >
>
> >
>
> >
>
> > jsval &window)
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > bool isSuccess = false;
>
> >
>
> >
>
> >
>
> > nsresult rv;
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > do
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > nsCOMPtr< nsIScriptGlobalObject > scriptObj = do_GetInterface( docShell,
> > &rv );
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > if( NS_FAILED( rv ) )
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > break;
>
> >
>
> >
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> > nsCOMPtr< nsIScriptContext > scriptContext = scriptObj->GetContext();
>
> >
>
> >
>
> >
>
> > if ( !scriptContext )
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > break;
>
> >
>
> >
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> > *jsContext = static_cast( scriptContext->GetNativeContext());
>
> >
>
> >
>
> >
>
> > //JSObject *globalObj1 = scriptContext->GetNativeGlobal();
>
> >
>
> >
>
> >
>
> > JSObject *globalObj = scriptObj->GetGlobalJSObject();
>
> >
>
> >
>
> >
>
> > CLogFile::Info(111, "CFFGBrowser::GetJSGlobalContextAndObject
> > -start...3.2.");
>
> >
>
> >
>
> >
>
> > //JSObject *globalObj = JS_GetArrayPrototype(*jsContext,globalObj1);
>
> >
>
> >
>
> >
>
> > //JS::Rooted globalObj(*jsContext,
> > JS_GetGlobalForScopeChain(*jsContext));
>
> >
>
> >
>
> >
>
> > //JS::RootedObject*globalObj =static_cast(
> > scriptContext->GetNativeGlobal());
>
> >
>
> >
>
> >
>
> > //JSObject *globalObj2 = JS_GetGlobalForScopeChain(*jsContext);
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > //JSObject *globalObj3 = JS_GetGlobalForObject(*jsContext,globalObj2);
>
> >
>
> >
>
> >
>
> > //JSObject *globalObj = JS_GetGlobalForScopeChain(scriptContext);
>
> >
>
> >
>
> >
>
> > if ( !jsContext )
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > break;
>
> >
>
> >
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > if (!globalObj )
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > break;
>
> >
>
> >
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> > JSBool isSucceeded = JS_GetProperty( *jsContext, globalObj, "window",
> > &window );
>
> >
>
> >
>
> >
>
> > if ( ( isSucceeded != JS_TRUE ) || ( window == JSVAL_VOID ) )
>
> >
>
> >
>
> >
>
> > {
>
> >
>
> >
>
> >
>
> > break;
>
> >
>
> >
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> > jsval jsargs[1];
>
> >
>
> >//jsval jscaptureSSLText = JSVAL_NULL, rval = JSVAL_NULL;
>
> >
>
> >jsval rval = JSVAL_NULL;
>
> >
>
> >jsargs[0] = INT_TO_JSVAL(0);
>
> >
>
> >//JS::HandleValue captureSSLVal = JS::RootedValue(jsContext,
> > jscaptureSSLText);
>
> >
>
> >JS::RootedValue captureSSLVal(*jsContext, jsargs[0]);
>
> >
>
> >JS::RootedValue windowVal(*jsContext, window);
>
> >
>
> >JS::RootedObject windowObj (*jsContext, JSVAL_TO_OBJECT(window));
>
> >
>
> >//JS_CallFunctionName
>
> >
>
> >JSBool isSucceededd = JS_CallFunctionName(*jsContext,
>
> >
>
> > globalObj,
>
> >
>
> > "KeynoteCaptureSSLText",
>
> >
>
> > 1,
>
> >
>
> > jsargs,
>
> >
>
> > &rval);
>
> >
>
> > isSuccess = true;
>
> >
>
> >
>
> >
>
> > }while(false);
>
> >
>
> >
>
> >
>
> > return isSuccess;
>
> >
>
> >
>
> >
>
> > }
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Regards
>
> >
>
> >
>
> >
>
> > Vasu
>
>
>
>
>
>
>
> Now, I have got pass through below items.
>
> 1) create instance of JS XPCOM component,
>
> 2) Call javascript XPCOM component funct
