Re: Xulrunner 16 to 17? (Erro compiling)
Em quinta-feira, 29 de novembro de 2012 14h48min56s UTC-3, Jeff Hammel escreveu: Wild guess in the dark here, and assuming `py` == the python executable, it looks like you're using python 3.x (again wild guess) whereas in python 2.x print getBuiltinOrNativeTypeName(self.params[0].realtype) is valid syntax. Again, its hard to guess from the limited information here. Jeff On 11/29/2012 05:41 AM, Felipe Junges wrote: No, we has using the old .bat with xpidl.exe It was working until 16. Is there some change in 17 that needs to use .py? Anyway... We have installed python, and running: py D:\xpcom_info\xulrunner\sdk\bin\header.py --cachedir=D:\ -o D:\xpcom_info\Informatize\comp.h D:\xpcom_info\Informatize\comp.idl Is giving us this error: print getBuiltinOrNativeTypeName(self.params[0].realtype) SyntaxError: invalid syntax A ^ in the last e from getBuiltinOrNativeTypeName :( When we tryed to update to 17 and start having those errors, we started thinking that maybe we were doing something wrong from the beggining (like use the EXE), but all tuto's on internet are not updated... Is there some tutorial that shows the correct way to create a extension, updated to version 17? Thanks a lot! Em quarta-feira, 28 de novembro de 2012 20h53min59s UTC-3, Simon Kornblith escreveu: Did you rebuild your automatically generated C++ headers using the version of pyxpidl shipped with XULRunner 17? Details at https://developer.mozilla.org/en-US/docs/XPIDL/pyxpidl On Nov 28, 1:48 pm, Felipe Junges felipejun...@gmail.com wrote: Hi! First, sorry about my poor english =P I'm brazilian... so... I'll give my best =P Where I work, we have a Firefox add-on, what was working perfect until xulrunner 16, compiling in Visual Studio 2010. Now, we have updated it to xulrunner 17 and we are getting lots and lots of erros, when trying to compile. Like: Code: d:\xpcom_info\informatize\comp.h(25): error C2470: 'ISpecialThing' : looks like a function definition, but there is no parameter list; skipping apparent body 1d:\xpcom_info\informatize\comp.h(38): error C2653: 'ISpecialThing' : is not a class or namespace name 1d:\xpcom_info\informatize\comp.h(38): error C2143: syntax error : missing ';' before '' 1d:\xpcom_info\informatize\comp.h(38): error C2988: unrecognizable template declaration/definition 1d:\xpcom_info\informatize\comp.h(38): error C2059: syntax error : '' d:\xpcom_info\informatize\comp.h(38): error C2039: 'kIID' : is not a member of '`global namespace'' 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(51): error C2989: 'nsAString' : class template has already been declared as a non-class template 1 d:\xpcom_info\xulrunner\include\nsrootidl.h(18) : see declaration of 'nsAString' 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(52): error C2989: 'nsACString' : class template has already been declared as a non-class template 1 d:\xpcom_info\xulrunner\include\nsrootidl.h(19) : see declaration of 'nsACString' 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(160): error C2332: 'enum' : missing tag name d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(160): error C2989: 'unnamed-tag' : class template has already been declared as a non-class template 1 d:\xpcom_info\xulrunner\include\nsXPCOM.h(252) : see declaration of 'unnamed-tag' 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(367): error C3861: 'NS_StringSetDataRange': identifier not found 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(392): error C3861: 'NS_StringSetDataRange': identifier not found 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(409): error C3861: 'NS_StringSetDataRange': identifier not found 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(465): error C2332: 'enum' : missing tag name 1d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(465): error C2989: 'unnamed-tag' : class template has already been declared as a non-class template And some more! We have made no changes in our code, when did the update. We have noticed that various errors are been reported in nsXPCOMStrings.h, the others are pointed in our code (that works perfect with xulrunner 16). It look like we have to put some include somewhere... Can anobody help us finding what did changed from 16 to 17, what does the programmers has to change? Our code is not much different from the XPCOM example: https://developer.mozilla.org/samples/x... m-test.zip That was explained here:https://developer.mozilla.org/en-US/doc... ual_Studio Ah! We have downloaded the example from
Updates applied to Contents/MacOS instead of application directory (.app), causing all updates to either fail or break the app XULRunner 17.0
This is what happens now: 1. Updates checked for in versino 0.0.1, says that 0.0.2 is available 2. The partial update downloads and applies as per above, and a restart is prompted 3. After restart, the old version is still running, and checking for updates downloads the full update 4. After restart, the full update installs and lands in Contents/MacOS/Contents/MacOS and Contents/MacOS/Contents/Resources etc, and the previous files are removed, thus leaving the app in a broken state, unable to run. Running cp -r Contents/MacOS/* . from the .app directory unbreaks it and allows starting the new updated version of the app. For instance, here is the log of a very small partial update: SOURCE DIRECTORY /Users/motin/tmp/My App.app/Contents/MacOS/../Resources/updates/0 DESTINATION DIRECTORY /Users/motin/tmp/My App.app/Contents/MacOS UPDATE TYPE partial PREPARE PATCH Contents/Resources/chrome/app.jar PREPARE PATCH Contents/Resources/application.ini PREPARE ADD Contents/MacOS/libsoftokn3.chk PREPARE ADD Contents/MacOS/libnssdbm3.chk PREPARE ADD Contents/MacOS/libfreebl3.chk PREPARE PATCH Contents/Info.plist PREPARE ADD precomplete EXECUTE PATCH Contents/Resources/chrome/app.jar unable to open destination file: Contents/Resources/chrome/app.jar, err: 2 ### execution failed FINISH PATCH Contents/Resources/chrome/app.jar backup_restore: backup file doesn't exist: Contents/Resources/chrome/app.jar.moz-backup FINISH PATCH Contents/Resources/application.ini backup_restore: backup file doesn't exist: Contents/Resources/application.ini.moz-backup FINISH ADD Contents/MacOS/libsoftokn3.chk backup_restore: backup file doesn't exist: Contents/MacOS/libsoftokn3.chk.moz-backup FINISH ADD Contents/MacOS/libnssdbm3.chk backup_restore: backup file doesn't exist: Contents/MacOS/libnssdbm3.chk.moz-backup FINISH ADD Contents/MacOS/libfreebl3.chk backup_restore: backup file doesn't exist: Contents/MacOS/libfreebl3.chk.moz-backup FINISH PATCH Contents/Info.plist backup_restore: backup file doesn't exist: Contents/Info.plist.moz-backup FINISH ADD precomplete backup_restore: backup file doesn't exist: precomplete.moz-backup failed: 6 calling QuitProgressUI The DESTINATION DIRECTORY ought to be /Users/motin/tmp/My App.app Updates work fine on Windows and Linux. Any help appreciated! PS I tried with 17.0.1 but then the app fails completely with Could not find the Mozilla runtime. regardless of what I do. Anyway I didn't find any update-related patches between 17.0 and 17.0.1 so I believe an upgrade to 17.0.1 wouldn't help anyway. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: automating gecko in-rprocess xpcom
I'm not sure what you mean because as best I understand it, the Selenium Firefox driver is an extension and thus runs in the same process space as Firefox itself. If you're looking for a closer binding between your automation code and Firefox, you can take a look at our new automation mechanism called Marionette that uses the WebDriver protocol to drive Firefox. (Marionette is wired inside Gecko in order to make this kind of automation easier). https://developer.mozilla.org/en-US/docs/Marionette Hope that helps, Clint On 11/30/2012 10:04 PM, mozz wrote: i've been using selenium firefox driver to automate firefox and it's too slow as communications between firefox and driver happens out-of-process. possible to embed gecko in a process and drive it/interact with its DOM directly via xpcom? thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Minimum Required Python Version
On 12/1/2012 2:29 PM, Gregory Szorc wrote: The bump to Python 2.6 seemed to go OK. So, I think it's time to finish the transition and bump the minimum to Python 2.7. Per the previous discussion on this list, I don't believe we have any outstanding objections. So, I propose we move forward with this as soon as we have confirmation that all builders are on Python 2.7. https://bugzilla.mozilla.org/show_bug.cgi?id=804865 is tracking bumping the /build/ requirement to Python 2.7. Some tests will still be running on older Python. But, I believe everybody is on board with transitioning everything to 2.7. So, we should pretend this transition effectively means we can stop supporting 2.6 and below everywhere in the tree as soon as 2.7 is deployed everywhere. If there are any objections, please voice them now. No objections at all. I just want to say that we should also review what the pending work is to bump the tests to 2.7 as well. That will likely have to happen after B2G automation milestones in Q1 2013 though, as we have no bandwidth to address the necessary bugs before then. Clint ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Scrollbar not rendered at top-level [Qt backend]
Native Theme implementation in Qt port is in very bad shape, and practically was never tested, because Qt XUL Fennec use css scrollbars, and native scroll indicators are disabled. there are 2 ways to fix this problem: 1) Fix Qt native themeing. 2) disable widget native themeing (set preference mozilla.widget.disable-native-theme = true) and use native default CSS scrollbars theme, or ajust it to be just indicators and not scrollbars. On Monday, 26 November 2012 20:30:30 UTC-8, Michael Goffioul wrote: Hi, I'm trying to use a Qt-build of mozilla as an embedded web browser. I've built mozilla for Qt from git sources and used a patched version of mozembed as explained in [1]. I've already detected and fixed 2 issues in mozilla sources, but now I've a problem with scrollbar rendering. Scrollbars are not rendered at top-level. They're rendered correctly in sub frames. See the following screenshots for an illustration: - mozembed1 [2]: page with frames, where scrollbars are rendered - mozembed2 [3]: page without frames, scrollbars are not rendered These screenshots are produced using my test embedding app, but I can reproduce the exact same result by running firefox from my Qt-build of mozilla. The weird colors in the first screenshot are due to modification I've made to nsNativeTheme.cpp to easily identify what was rendered where. Obviously the missing colors in the second screenshot is a hint that scrollbars are not rendered properly. Would anybody have some hint where I should look at to track down the issue? I don't mind digging into the code, but given the size of the code base, any hint will be greatly appreciated. From my first debugging attempts, I can tell that rendering code is executed and scrollbars are painted into some gfxImageSurface (width = 64, height = window height; not sure why the width is 64 as the scrollbar should only be ~17 pixels wide). However when this is transfered later on to Qt, through nsWindow::DoPaint, it's using another gfxImageSurface object, namely gBufferSurface defined in widget/qt/nsWindow.cpp. Thanks, Michael. [1] https://groups.google.com/group/mozilla.dev.embedding/browse_thread/thread/0db32900d2ff53ca# [2] http://picpaste.com/mozembed1-cwDoOT2O.png [3] http://picpaste.com/mozembed2-KFTOssgU.png ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Requiring Python 2.7 to Build the Tree
I originally sent this as a reply to the Minimum Required Python Version thread. Per request, I'm reposting as a new topic so it doesn't go unnoticed. We will also likely discuss this at the engineering meeting tomorrow. SeaMonkey has also requested an additional week to switch things over, so there will likely be no action until after the weekend. Original message follows. --- The bump to Python 2.6 seemed to go OK. So, I think it's time to finish the transition and bump the minimum to Python 2.7. Per the previous discussion on this list, I don't believe we have any outstanding objections. So, I propose we move forward with this as soon as we have confirmation that all builders are on Python 2.7. https://bugzilla.mozilla.org/show_bug.cgi?id=804865 is tracking bumping the /build/ requirement to Python 2.7. Some tests will still be running on older Python. But, I believe everybody is on board with transitioning everything to 2.7. So, we should pretend this transition effectively means we can stop supporting 2.6 and below everywhere in the tree as soon as 2.7 is deployed everywhere. If there are any objections, please voice them now. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Mon, Dec 3, 2012 at 11:32 AM, Norbert Lindenberg mozillali...@lindenbergsoftware.com wrote: As part of implementing the ECMAScript Internationalization API [1, 2] in SpiderMonkey, and as an aid in internationalizing other functionality in Mozilla products [3], I need to integrate the ICU library (International Components for Unicode [4]) into the source tree and the build. For integrating ICU into the source tree, I see two main alternatives: - Add the required set of ICU source files as separate files to the Mozilla repository. The current version of ICU (50.1, C/C++ version) has about 5350 source files; stripping out files that aren't needed for the internationalization API (but might be needed later) brings this to about 3250 files. The complete Mozilla tree before this addition has about 70,000 files. - Add the source bundles (zip/tar) to the Mozilla repository, and then extract the source files as part of the build. One might also imagine leaving ICU out of the tree entirely, and either downloading the sources as part of the build, or building ICU completely separately and only installing the binaries, but neither of these options seem appropriate. Comments? Thanks, Norbert [1] http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts [2] http://norbertlindenberg.com/2012/10/ecmascript-internationalization-api/index.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=724529 [4] http://site.icu-project.org ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform We should just add the ICU sources to the tree. The complexity of extracting/downloading the sources during the build would be high, and we don't do that for any other third-party library. I'm far more worried about ICU's impacts on the size of the binaries we ship to users than I am about the impact to the size of our source tree ;-) - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Mon, Dec 03, 2012 at 09:11:58PM +0100, Mike Hommey wrote: On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote: On 12/3/2012 2:32 PM, Norbert Lindenberg wrote: As part of implementing the ECMAScript Internationalization API [1, 2] in SpiderMonkey, and as an aid in internationalizing other functionality in Mozilla products [3], I need to integrate the ICU library (International Components for Unicode [4]) into the source tree and the build. This has been brought up many times over the years, and each time previously we decided not to import ICU. At first, the license was incompatible; that has since been fixed. Now the question is mainly about whether the features ICU provides are worth the really cost in terms of binary size. How much size does ICU cost, if we took the entire library? How much of that is data (which can be shared in 32/64 mac universal builds) and how much is code which cannot be shared? ICU doesn't come with data files. Data is enclosed in libraries, and such data is not shared between the 32-bits and 64-bits parts of universal binaries. FWIW, the libicudata.so file on my debian install has about 18MB of .rodata. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Layout issue involving scaling
I've seen issue https://bugzilla.mozilla.org/show_bug.cgi?id=504071 in a lot of sites I've been working on recently. There are white lines between two adjacent scaled images. I'd like to help with a fix, if possible. Does anyone have any deep insight into this bug that could point me in the right direction? Thanks, Brad ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg mozillali...@lindenbergsoftware.com wrote: Well, the first question is what size increase would be acceptable given the benefits that ICU provides. I have currently trimmed it to 9.7 MB for the data library and 3.1 MB for two code libraries. Ignoring download size for a moment, I want to consider the memory usage of this at runtime. Does all of this data need to be loaded into memory? If so, 13mb of code + data is likely unacceptable to B2G. That's roughly 10% of all memory we have available to gecko on our devices. I would lobby hard against turning this on for B2G. If we can avoid loading most of that data into memory, the situation is much better. But even 3mb of code is dicey; we consider a 3mb memory win to be substantial and worthy of a large amount of effort to obtain. I'd imagine that the Fennec folks working on project 256mb [1] would have similar reactions. On Windows desktop, our median memory usage is ~500mb, and the 5th percentile is ~175mb, so an extra 13mb, while not great, might be acceptable. 3mb wouldn't be a big deal. -Justin [1] https://bugzilla.mozilla.org/show_bug.cgi?id=792131 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On Dec 3, 2012, at 16:15 , Justin Lebar wrote: On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg mozillali...@lindenbergsoftware.com wrote: Well, the first question is what size increase would be acceptable given the benefits that ICU provides. I have currently trimmed it to 9.7 MB for the data library and 3.1 MB for two code libraries. Ignoring download size for a moment, I want to consider the memory usage of this at runtime. Memory usage on small devices certainly warrants some investigation and discussion. Unfortunately, I don't have real data yet. Does all of this data need to be loaded into memory? Most of the data is locale data for several hundred locales, separated by locale and functionality, so as long as applications don't request a specific locale/functionality combination, it doesn't need to be loaded. Note though that the size of the data isn't uniform per locale - e.g., Chinese collation data is huge. If so, 13mb of code + data is likely unacceptable to B2G. That's roughly 10% of all memory we have available to gecko on our devices. I would lobby hard against turning this on for B2G. Understood. Now, how does B2G support internationalization in the absence of ICU? If we can avoid loading most of that data into memory, the situation is much better. But even 3mb of code is dicey; we consider a 3mb memory win to be substantial and worthy of a large amount of effort to obtain. Is all code loaded into memory as one lump on B2G, or is it paged in as needed? There may be quite a bit of code in there that's not commonly needed. The ICU documentation suggests static linking as a way to reduce code size - I haven't tried yet how much that would help. I'd imagine that the Fennec folks working on project 256mb [1] would have similar reactions. On Windows desktop, our median memory usage is ~500mb, and the 5th percentile is ~175mb, so an extra 13mb, while not great, might be acceptable. 3mb wouldn't be a big deal. Good to know. Norbert ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
