|
10:30 pm
[tqh]
[Link] |
Fork
If anyone who helped with the port is interested we have a real fork. If you want to contribute your old patches we never got to CVS, contact me. It's just so we can create a stable port, which has been impossible until now. (We are not going to fix the fact that most of the code exists in the preprocessor though.)
|
|
09:17 pm
[mdisreali]
[Link] |
question about behaviour
I've recently started testing daily haiku builds and noticed that when I double-click the BeBook link on the desktop two instances of the browser open. Has any one else experienced this? And, where should it be reported? Haiku-Ports or Dev-Haiku?
|
|
01:46 pm
[mmadia]
[Link] |
Some updates ...
Haiku builds, HaikuPorts as bugtracker, Haiku404, HaikuFox, ...
( Read more... )
|
|
01:43 pm
[mmadia]
[Link] |
One final hoo-rah for 1_8_BRANCH (?)
Lately, I've been doing some Mozilla work inside Haiku.
( Read more... )
|
|
09:18 am
[tqh]
[Link] |
Time for something completly different?
I've grown (very) tired of trying to get code into Mozilla base. I just failed getting a patch reviewed that increases stability, quality and speed of Mozilla on the sole argument that they don't like a structure in the OLD Mozilla-code (and I don't change it structurally). This means it won't go into Firefox 2 and there is no chance to fix that now. Adding stuff to a 310k patch isn't very smart anyway, especially when it's something that would be much more suited for a bug of it's own.
Anyway...
Now that Firefox 2 is nearing end of life*, it's a good time to stop for me as well.
I'll be around, but I won't be working much on anything I need to talk with Mozilla about.
*) And without any BeOS/Haiku improvements at all since I've been stuck waiting for this review.
|
|
02:25 pm
[tqh]
[Link] |
Firefox2 for Haiku
Well, not yet. I've come to the conclusion that there is no chance at all to get all the changes for Haiku into mozilla code before Firefox2 end of life. So it's time for plan B.
Plan B is described in Mozilla Licensing under "I want to distribute a modified version of Firefox (or other MPL-covered code). What do I have to do?"
* We need to list and make the modifications available on the net for at least 12 months (no problems)
* Add MPL headers to new files (no problems, only a few NSPR-files)
* Include a statement that your code is derived from the particular piece of MPLed code you started with (e.g. Firefox), and a list of the names of the Initial Developers of that code (just point to mozilla page?)
* We probably need a Mozilla Foundation trademark license for (the Firefox name or logo).
According to the policy on trademark usage we need one as it will be some 'serious' modifications.
Before we put forward a request at Trademark Usage Requests, is there any opinions and comments, and maybe even a good wording for such a request?
I guess that the changes to Firefox should probably be fairly limited to get their approval:
* gcc4 fixes
* configuration changes for Haiku building
* bugfixes for Haiku building
* new NSPR (if not checked in)
* Native colors fixes
* Native executable (by hand or by mmadia modified patch)
* port setup fix.
* other?
|
|
04:20 pm
[tigerdog]
[Link] |
Firefox 2.0.0.18 now available on BeBits
The Mozilla Foundation today released Firefox 2.0.0.18, a security and stability release. I've completed the usual NetServer, BONE/Haiku and Zeta builds and they are available now for download from BeBits.
|
09:58 am
[tigerdog]
[Link] |
New NSPR Definitely fast!
I just downloaded the latest 96MB Haiku pre-alpha using a unoptimzed, debug build with the new nspr. I sustained better than 1100Kb (8.8Mbps) during the transfer. Nice work!
|
|
03:54 pm
[tigerdog]
[Link] |
Dropped data and incomplete images
I've been using a BONE build of Firefox with tqh's NSPR under Haiku for quite a while and I've noticed that many pages do not load completely. Often, images only load or display halfway, or the page layout is corrupted. I've made a debug build and have noted some unusual entries in the console output. Read more for a sample.
( Read more... )
|
|
08:11 pm
[tqh]
[Link] |
Trying to get 310k of code reviewed :)
Ok, I finally set the review-flag on the first parts of the NSPR-patch. I finally feel it's been cleaned up enough for review, it has been tested for a long time and now I and a few others have used it a bit under Haiku.
I hope we will get it in quite fast, but I believe that it may be a bit problematic given the size.
Anyway I'll take the NSPR-patch code over the ordinary any day. Heck, it has even given me over 4MB/s downloads under Haiku.
Bug number 300595 btw.
|
|
10:23 am
[tqh]
[Link] |
Our development tree in Mercury
I've started to push some patches into the Mercury tree. Currently they are
* configure changes for crosscompiling and for Haiku support.
* NSPR-rewrite
Planned changes are:
* Much faster widget code (CallMethod restructuring)
* Look and feel (tigerdog?)
* Fixing bugs for Haiku integration
This tree is for developers only, if you are one and need access let us know. The aim is to get all changes into Mozilla thru bugs as usual, and with Firefox 3's own Mercurial this tree will not even be needed.
|
|
06:47 am
[tigerdog]
[Link] |
No downloads under Haiku in latest branch build?
The latest BONE builds of Firefox and Thunderbird work fine under BONE and Zeta, but will not download files under Haiku. At first I thought this might be an issue with tqh's new NSPR but it also happens with the standard NSPR. Again, the builds work fine under BeOS/Zeta but fail under Haiku. Is this a Haiku bug to be filed?
Update: works now, with 29 October Haiku nightly.
|
|
10:46 pm
[tigerdog]
[Link] |
NSPR Patch 300595 nearly complete
just a note to let folks know tqh has pretty much finished his cleanup of NSPR. the new version seems snappier and more responsive than previous builds. Hopefully we'll get it committed prior to 2.0.0.18's release and before the branch shuts down at the end of the year.
|
|
10:48 am
[tigerdog]
[Link] |
NSPR Patch 300595 building now
OK, not sure if my changes were correct, but at least it's building here. Needed to change two files:
prlink.c: moved definitions to top of #if structure like this
#ifdef XP_BEOS
{ /* Code block to allow variable inits. :/ */
/* it appears the library isn't yet loaded - load it now */
image_info info;
int32 cookie = 0;
const char *endOfPassedName = strrchr(name, '/');
const char *endOfSystemName = strrchr(info.name, '/');
#ifdef XP_HAIKU
image_id imageid = load_add_on(name);
#else
image_id imageid = B_ERROR;
image_id stubid = B_ERROR;
char stubName [B_PATH_NAME_LENGTH + 1];
but I'm not sure I understand how the ifdefs flow here. If I'm reading correctly, since there's no "}" before #ifdef XP_HAIKU, it looks like the check of XP_HAIKU only gets executed if the check for XP_BEOS has already been passed. I think this should work, maybe?
bproc.c: the patch removed "#include signal.h" but that's where "SIGKILL" is defined. build failed at line 221 until I put this include back in.
|
|
10:11 am
[tqh]
[Link] |
Hacking and IRC Saturday 11/10?
Instead of a meeting I plan to try to be available this saturday from around 11:00 to 19:00 CET on IRC at #bezilla on irc.mozilla.org. If you would like to join/ ask questions or maybe help test some code* just be there.
I was planning on going to BeGeiestert this time, but unfortunatly I couldn't fit that in. At least stippi got me more motivated to push for a better integrated Firefox for Haiku.
* mostly for those who know how to build/patch Mozilla apps under BeOS/Zeta/Haiku. (I have a lot of code that needs testing, accumulated over a long time that is almost ready for checkin.)
|
|
10:22 pm
[tigerdog]
[Link] |
False Alarm (was: uh-oh: branch building broken )
sometime between 2008-09-21 and today, something landed on the branch that causes trouble. While the build completes OK, the resulting Firefox never opens its initial window. When run from the terminal, no error message is seen. I'll see if I can figure out what made the change.
Update: must have been a corrupted tree. Pulled a clean 2.0.0.17 then updated to latest and now all is well. Sorry for the false alarm.
|
|
10:41 am
[tigerdog]
[Link] |
Incomplete page loading on Haiku
I'm unable to successfully load http://www.bakerprecision.com when running FF2.0.0.17 under Haiku. Graphics either don't load at all, or only load partially. Moreover, refreshing the graphic or displaying it in a separate tab doesn't work either.
Works fine with FF2.0.0.17/Zeta as well as FF3/WinXP and Chrome/WinXP. Not sure whether to report this as a Firefox bug or a Haiku bug, but I suspect Haiku. Thoughts?
|
|
02:40 pm
[tigerdog]
[Link] |
Firefox 2.0.0.17 now on BeBits
Just what it says on the label. Sorry for the delay in posting these.
|
|
11:20 am
[tigerdog]
[Link] |
Theme colours wrong under Haiku
This was being discussed in an unrelated thread so I thought I'd start one dedicated to the topic.
I wrote "I think this may be a Haiku problem, not Firefox. I'm not quite sure why this happens. Firefox's default theme pulls colors from the system palette, supposedly. This seems to work fine under BeOS and Zeta but not Haiku. You can (of course!) install HaikuFox theme. HaikuFox uses hard-coded colors to look more BeOS-like."
tqh replied, "Yes, as I built specifically for Haiku I thought it used some UNIX ifdef somewhere, but it is true even with BeOS builds, so Haiku is doing something different or we make an assumption that is no longer true. I can't remember where this code is and havn't managed to locate it. I think Sergei would know though."
Thanks to clean living and a lot of time spent on HaikuFox, I believe the offending code starts here: http://mxr.mozilla.org/mozilla/source/widget/src/beos/nsLookAndFeel.cpp#54
Anyone care to guess why Haiku behaves differently?
|
|
09:12 am
[tqh]
[Link] |
Crosscompiling Firefox
I was too tired yesterday to complete my wiki article on crosscompiling Firefox for Haiku, but it's almost all there except for the patches needed. I will try to finish it this evening.
Anyway here is the article: Crosscompiling Firefox
Have fun, and don't hesitate to ask anything.
Update:I think I'm done so go ahead and try it out. Note that the PrNetAddress patch is quite important and should probably be used in BeOS as well. It might be what breaks ssl for some. The structure was smaller than it supposed to be on BeOS/Haiku probably from R4-4.5 porting.
|
![[info]](http://l-stat.livejournal.com/img/community.gif){kind=small}
bezilla