User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0 Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0 This bug tracks the different bugs that need to be fixed before a BeOS release of Firefox 1.0. It also is the bug for the BeOS related release notes. Reproducible: Always Steps to Reproduce:

Assigning but to me. The Japanese Input patch needs some cleanup before it's ready for inclusion, but that should be manageble. The transparancy fix would be very nice to have fixed, but I don't know to what extend that will be done. We'll see. Whether or not to include the native app patch, that will still need some debating.

I personally think we should try and get bug 104729 up to date. Doing native app right would require fixing threading issues in widget / gfx and solving library-loading (addon-path, library-path set by script)

Adding bug 104729 (for now). Expect it in development release 3. Niels

Adding bug 244701. I need someone with a bone build to verify that this site works. If so, we can close another bug ;-)

Oops... sorry for the mid-air collision. I'm putting Bug 244701 back in the depends list. Prog.

bug 244701 is closed.

Adding two bugs relevant to download-locations. Bug 255189 and bug 264512. (These two really annoy me.)

Can't save prefs bug reported, bug 266327

Reported bug 266328 'add bookmarks doesn't close'.

Some twidling around... Bug 255189 seems to be a linux bug, that is present in the BeOS tree as well. In order to be able to succesfully close the bug, I have created bug 267219 . The patch included with that one is my first one! (hurray!!!). These updates are for 1.0.0-d3

Well my fault. I thought the directory selection was a xul/platform independent thing. Anyway, nice to see you're working :)

Bug 267823 is now closed. This is merely a stylistic change (I think), but it affects the Japanese input patch. So keep this in mind when updating CVS.

Adding the moz_icon annoyance.

Adding bug 271613 to this list, although I don't think it will change in the AVIARY branch. I suspect this will help the startup troubles.

Adding the startup bug (and coming patch).

I'm going to concentrate on the trunk now. This seems a better decision, based on the fact that it gives us a better frame of improvement. It also might motivate people better.

So is my plan, once I get the build I have in shape.

I've added a new bug which handles the misplaced menus and drop down lists(and stuff). This is an absolute showstopper.

More 'fixed' bugs will come today :)

Added a minor bug so we don't seek to end when there is no need.

Removing bug 264512 from dependency as I will submit a new bug which fixes it.

Adding the reopened bug 169506

Adding another cleanup bug 276373 and preparing for the days when the users desktop doesn't live on the /boot volume.

Adding bug 276378 which should make 'Desktop' actually resolve to '/boot/home/Desktop'

Fix the transparancy memory leak.

Adding _MD_access bug.

Added Sergei D's GFX rewrite. Updating this bug to reflect the 1.1.0-d4 build

Adding the bug for the 'base part' of my native app support. See bug 281375

Adding bug 282031

Add the CTRL W issue (this will be in build 1.1.0-d4)

Adding a few bugs.

Do not reshedule on release_sem added. Bug 283210.

Adding bug 283629 which seems to improve snappiness quite much.

I'd vote for adding 220753 (mailto: links) to the list, since it appears the work is mostly done but the patch is not checked into CVS. Thoughts?

Sure, go ahead :)

done. I always feel I should ask permission, since I'm really just a tester and not a dev.

Drop the 'restart' bug. This won't be tackled before 1.1 anyway (and we don't have enough influence to get this especially for us anyway).

added bug 291168 If anyone wants to take a look at it...

Added bug 294234 as I think I will keep image-support in DND.

Added bug 298171 - Scrolling with mouse over iframe (and maybe other views) jumps around

Adding bug 296849 and bug 296823 which I forgot before.

duplicated again tonight with a clean build from CVS - same issue. Anyone?

(In reply to comment #42) > duplicated again tonight with a clean build from CVS - same issue. Anyone? Posted in wrong bug. comment pertains to 308194, not the tracker bug. But I'd appreciate someone confirming the bug exists.

Let's get this thing rolling for Firefox 1.5 :-)

Added bug 129310 as it improves scrolling a lot.

Here is another bug, that is nice for performance, bug 296856. I think we should have it in 1.5 if possible.

agreed on 296586. Makes for a much snappier browsing experience.

Adding popup-fixing bug 310293.

Adding bug 310680 which apparently is fantastic for performance.

Oops, the performance is apparently from a yet to be filed bug. My mistake. Anyway it seems good things are in the works :)

Move bugs not for Firefox 1.5 to bug 311032 (Firefox 2.0 tracker). Even though I personally consider the DnD patch a feature, I acknowledge that in order to make a fully clean CVS build, that this patch is something we need to land for 1.5.

This is the 'official' Firefox 1.5 beta 2 .mozconfig. Please note that the file has been tested, but not the checkout flag, which can only happen if the tagging is done. So at the moment, this is a proof of concept, but as soon as the tree is closed I can verify if this file works, and update it if needed.

Clear dependency no longer neccessary.

Only two patches to go: bug 311651 and after that bug 104729

Just to make a thing clear, I'm desperately hoping that the RC1 is flawed :-) I really want to have a CVS-buildable release, but if it turns out not the case, there's no problem. For some magical reason the bug 104729 is fixed now, I'll upload that patch as soon (and if) bug 311651 lands (which should make diffing easier). I'll upload the blog later today.

Anther important bug. That leaves bug 311651 , and bug 104729 , as well as bug 314330 to be committed in the 1.8 branch.

(In reply to comment #56) > Anther important bug. That leaves bug 311651 , and bug 104729 , as well as bug > 314330 to be committed in the 1.8 branch. > Bug 311651 was just checked in by biesi. That leaves bug 104729 and bug 314330. I'll just wait until the anonymous cvs is synchronised, so that I can make a custom 104729 patch. I hope it's all going to work out

Bug 104729 was checked in by timeless. This means that only bug 314330 needs to be backported. It seems like some of the changes are already in, so I'm just looking how to shape this patch.

If we can build Firefox cleanly with such a minimal .mozconfig, is there any reason for us to recommend the more complicated version found on the BeBits wiki?

There's no reason whatsoever to use the one on BeBits. My builds with this configuration are somewhat different in size, but there is no noticable difference whatsoever. My guess is that without explicitly mentioning extensions, we get a few extra for free. Furthermore, the configuration on Bebits might be a bit redundant anyway. So I'd vote for this kind of mozconfig.

An additional notice: bug 314330 has been checked in on the MOZILLA_1_8_BRANCH. As far as us is concerned, the BeOS release of Firefox 1.5 is ready to go.

I posted on BeZilla blog about how that mozconfig came into existance. It should be cleaned up and moved over to developer.mozilla.org ports page IMO.

http://developer.mozilla.org/en/docs/BeOS_Build_Prerequisites already has a mozconfig file. It doesn't mention non-BeOS specific options because they are documented on the general Configuring Mozilla page. I tried a few times to remove redundant/unnecessary options from the BeBits wiki. But some of the options there disable features that aren't disabled by default, so I left them in there. I don't understand why bebits disable IPv6. Is it just for the codesize effect? Not disabling it should not have any adverse effects...

ac_add_options --enable-default-toolkit=beos that's not needed

(In reply to comment #65) > ac_add_options --enable-default-toolkit=beos > > that's not needed > I'll try that for the next build.

I understand the desire to make as vanilla a build as possible for the release version. Would -enable bthreads compromise this? I've noted performance improvements here since including this in my builds. I believe this flag just allows firefox to take better advantage of BeOS's native threading capability. Just curious.

why is that not the default?

biesi, maybe it *is* the default. I've seen several .mozconfigs specify it over the years. Please excuse my ignorance, but is there a common location where one can easily see what items are enabled and disabled by default?

configure.in / nsprpub/configure.in

I created that mozconfig a long time ago for Phoenix. In those days it was actually very hard to get one that worked. So many things where disabled. The configs here is better for ordinary use.

"configure.in / nsprpub/configure.in" Thank you, biesi! In reviewing other options set here, it seems we could also set the default optimization to -o3 if we wanted to. Since the advent of the 2.95.3 compiler for BeOS, this seems like it might be a worthwhile change to make at some point.

http://www.bebits.com/app/3143 Firefox 1.5 stable is released! Closing this bug, it has served its purpose.