A problem was noticed with the WIP patch from bug 469443 applied. When typing in the search box, sometimes search-suggestion entries would be displayed above the divider. The problem is nsSearchSuggestions.js is passing the SuggestAutoCompleteResult result, instead of it being the previous form history search result. The bug wasn't visible before 469443, because nsFormFillController::StartSearch tries QI to provid result to nsIAutoCompleteSimpleResult. The search-suggestion result is nsIAutoCompletResult now, so QI fails and Satchel is doing a new search everytime. A fix was proposed, but wasn't quite right. Satchel should be smarter about throwing away a previous result when the previous result's search string doesn't have a common prefix. Another fix was proposed later, where the service's form history result copy is discarded when startSearch() is called with a null previous result. There was a ._formHistoryResult in the SuggestAutoCompleteResult wrapper and also a ._formHistoryResult in SuggestAutoCompleteIt. It was suggested to rename one of them to _fhResult. The one in the wrapper was renamed to _formHistResult. This bug was pushed http://hg.mozilla.org/mozilla-central/rev/097598383614. When typing in the search box, sometimes suggestion entries are displayed above the divider, where the previous matching searches are displayed. The problem is that nsSearchSuggestions.js is passing the SuggestAutoCompleteResult instead of the previous history search result, so entries from suggestions leak into history result. A patch was added to fix this problem. Further changes added to fix a problem with the patch. A problem in search box functionality is noted, which puts search suggestion entries above the divider separating them from previous matching searches. This is happening because the incorrect data structure is being passed to the form history, which contains both form history and search suggest entries. As the results change as the user types in the search box, this allows suggestions to leak into the form history, resulting in the separator appearing to be in the wrong place. An incomplete patch is offered, but the system needs to be smarter about throwing away previous results. It turns out there are .formHistoryResult fields in two data structures, one of which needs to be discarded. It is suggested and accepted that one should be renamed for clarity. A pref in Firefox provided for Session Store functionality causes problems when users deactivate Session Restore ability. In order to make removing this pref up, extension authors are suggested to take care of it in their own way. Some privacy issues are considered when people do not like their session history to be stored. However, these issues could be resolved by previously provided prefs. Some interferences with other packages is spotted then, but using already provided options or changing the documents will resolve it too. It is suggested to remove the preference that removes the session storing feature, because disabling it breaks some features. It was originally intended for extensions to disable when they do their own session restore, but can leave users with it still disabled after the extension is disabled. Instead the extension writers should extend the API to do session restoration themselves. Those users concerned with the privacy implications can disable other settings to effectively to the same thing. It is suggested that the browser.sessionstore.enabled preference be removed because it isn't working out as expected. An alternative of getting extension authors to override other settings to get the same result is proposed. A patch is provided. Possible privacy concerns are raised about how the patch works. Alternative solutions to the privacy issues are suggested. A minor change to the patch is given, but this is only because of another bug. The impacts of this change on another feature, Tab Mix Plus, is listed. The owner of this feature doesn't see a major problem, but requests a new preference be added to help with the change. A list of possible work-arounds is given. A request for proper documentation of the change is made. The multitouch \"rotate\" gesture for changing the active tab can sometimes be triggered accidentally, though not everybody seems to have this problem. This gesture was removed from Windows and OS X builds. Rotate gesture on multitouch trackpads causes cycling tabs in Firefox, but users might accidentally trigger it and get confused. This gesture could be tweaked not to be triggered accidentally. Also, pinching gesture causes zooming in/out, but since it is more natural there is no need to remove it. Sometimes zooming in/out are mistaken for rotating or vice versa, but removing rotate gesture will resolve it. Multitouch trackpads might not be an issue for Win7 users, but it is taken out from both versions anyway. There is a rotate gesture in Firefox that is often triggered accidentally while scrolling. It is agreed that the rotate should be removed in Windows and OSX in the next version of Firefox. It is suggested that the pinching gesture be removed as well, but it is decided that that should be in a separate thread. The method FolderDescription#createExistentResourceFromHandle(IResource,IProgressMonitor) does not create members that rely on the creation of other members not initially present. Initial suggestion is that createExistentResourceFromHandle should instead check to see if members of a FolderDescription should be created. Note that this is only a problem if code is structured inappropriately, and fixing it would require tracking changes to the file system that are outside the scope of the current class design. Javadoc was updated to clarify that the existing class does not track these changes, and additional validity tests were added. An error occurs where two file/folder creation operations that depend on each other are executed. The file system structure changes, invalidating the second operation, even though it is conceptually a valid operation. It was impractical to change this behavior, so the API was changed to check the validity of an operation, and the documentation is updated to clarify. If the class FolderDescription has nonexistence members, its method createExistentResourceFromHandle returns immediately, and as a result, these members will not be created. This problem occurs when portions of the resource tree which do not exist when the operations are created are already exist at the time of executions, because the operations remember that the portions of the resource tree don't exist. To solve the problem, we need to change operations so the resource descriptions are updated according to changes that occurred In addition, clear documents should be added to explain the intentions of the operators. This is a suggestion for enhancement so that lines added in a patch can be counted during \"Apply Patch\" wizard. Regular expressions which counts lines starting with '+' is preferred and simplest approach to achieve this. Same approach can also be extended to lines removed just by replacing '+' by '-' in the regular expression. As the first fix tried, user can specify the regular expression on the preference page and it is empty by default. This solves the problem but does not work out of the box. So another fix is tried which does not require that a regular expression is provided, however user can specify his/her own regular expression on the preference page. On testing it was realized that this also counts empty lines and a suggestion was made that output should also specify non-empty lines as filtered output like-\"Patch contains 207 added and 29 removed lines (151 / 27 filtered)\". The default behavior is simple and user has a choice to make changes to regular expression to achieve more sophisticated output(for example it ignores empty lines). This fixes the current issue and a more sophisticated default behavior is not required. Filter idea is good but it should be dealt as a separate bug. A new feature is suggested for the Apply Patch Wizard. When applying a patch the number of lines added and removed is displayed. The default counting method works by counting all lines that start with '+ ' as added, and all that start with '- ' as removed. The user can also use custom regular expressions to count added and removed lines, and can configure them from the preferences. An extra feature is suggested for being able to filter out lines from the count, such as lines with comments or empty lines, but it is no longer discussed, or it is discussed in a different bug report (unspecified). This thread is about a feature in eclipse which counts how many lines does a patch, change in the code. The first idea is embedding counter in apply patch wizard using a regular expression as ^\\+? (\\s*\\S+\\s*)+$ which counts lines starting with '+' and a space and have at least one non-space character. Then further discussion is about improving the regular expression which finally leads to ^\\+\\s+\\S as a default regular expression. Another discussion area is about counting removed lines and added empty lines, by the patch and some ideas for doing this is mentioned and implemented. As a solution, it is suggested to access user to put his regular expression for counting in General > Compare/Patch preference page and there is some discussion on what expression to pick for default value of regular expression. This report is about an incorrect deprecation comment in javaDoc for platform.getResourceString(Bundle,String). JavaDoc suggests using NLS or BundleFinder.find() instead of platform.getResourceString. Functionality of Platform.getResourceString is never implemented in any other class which is inconsistent with javaDoc. and many adopters are still using it. It turns out that javaDoc is incorrect and in fact Platform.getResourceString is not deprecated, and incorrect comments are fixed. The JavaDoc for Platform.getResourceString(Bundle,String) states that the method has been deprecated. It is confirmed that the method is not deprecated, and that the comments should have been added to the implementation code or to a bug report, not to the JavaDoc of the Platform class. The fix is to remove the comments from the Platform class. A bunch of comments in the javaDoc have never been acted upon. As a result, some classes and functions in the javaDoc have never been implemented. In addition, the classes which are assumed to be dropped are in fact not deprecated. Therefore, the comments in javaDoc should be removed to prevent confusion. The removing of these comments has been added to a milestone. In fact, this bug is a duplicate to another bug (247983). Some internal about pages in Firefox are hardcoded to be left-to-right, which causes some cosmetic problems in localized right-to-left versions of Firefox. Adding an extra option in the CSS file is suggested. However, fixing this in the markup language itself is more preferable. The directionality of internal pages are suggested to be controlled by an option mentioned in the language packs, which might cause problems in some pages. The problem is pushed to a higher level and left to be dealt with by localization authors after all. In localizations for languages that use RTL layout, the about:mozilla page is LTR. Other internals about pages have the same problem. The reason this bug has emerged is explained as being because about:mozilla has been moved out of the language pack. A solution using dom/chrome/global.dtd is suggested. A patch doing this is provided. There is discussion of the best way to mark directionality. It is suggested that a more global solution would be appropriate. In response, the patch is defended assuming the localizers finish their work properly. The case of about:robots is singled out as a special case that shouldn't be handled in this fix. There are calls to get this patch approved for the 1.9.0.1 release. Ownership of the approval is uncertain. The JavaDoc for IAdapterManager.computeClassOrder(Class) doesn't match the implementation. An example was provided to show the confliction. The comment, \"(in the example, A and its superinterfaces then B and its superinterfaces)\", in JavaDoc was not clear and it conflicted with \"a breadth-first traversal of the target class's interfaces in the order returned by getInterfaces\". A correct spec was proposed as \"a breadth-first traversal of the target class's interfaces in the order returned by getInterfaces (in the example, X and its superinterfaces then Y and its superinterfaces)\". The confliction between implementation and spec was made inadvertently while fixing bug 32498. Fixing the implementation was proposed as a solution. A test case was provided. A further modification, \"(in the example, X's superinterfaces then Y's superinterfaces)\", was suggested. It was accepted and released to the head. The AdapterManager.computeClassOrder(Class) implementation does not match IAdapterManager JavaDoc. At first it was suggested to change the spec to match the implementation. But it was discovered that the implementation used to match the spec, and was accidentally changed during an update. Since it was an accidental change, the fix is to change the implementation back to match the spec once again. The JavaDoc was also changed to remove a contradiction and make the methods behaviour clearer. This bug talks about mismatch in implementation and it's specification in JavaDoc for IAdapterManager method computeClassOrder(Class). Javadoc uses an example which does not catch the ambiguity very well. A richer example is presented to realize that the search order in which classes and interfaces are returned does not match with the specification. Specification in JavaDoc itself is a bit ambiguous. There is a concern that changing implementation to match specification may lead to loss of backward compatibility. This bug did not exist before February 20, 2004 and an accidental change lead to this issue, hence it was decided that implementation should be changed. Implementation issue is then fixed and tested with richer example. Minor changes to documentation make specification unambiguous. This is a suggested enhancement which will enable Firefox to support web based e-mail clients like gmail. Clicking a mailto link is generally useless as most of the users use web based email application. Other user programs and extension can possibly solve this problem, however Firefox itself should have this capability. This behavior can also be extended to feeds. Apparently Gecko 1.9 is required for this fix but using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1)Gecko/20090615 Firefox/3.5 solves the problem. Firefox supported a lot of stand alone e-mail applications, but not web based e-mail clients. The idea of providing an option to configure firefox to log into that web based e-mail account and open a compose new message window was suggested. One solution to this was to ask Firefox users to download the WebmailCompose extension from webmail services, but it was preferred to have an option in Firefox. The problem was fixed in a more recent version. This report is about the mailto: links in firefox which do not always work with web based e-mail clients when user clicks on these links. Users claim that this option is supported for stand alone e-mail applications (e.g. thunderbird) and also when webmail compose extension is installed. It turns out that a more general topic is discussed in another thread. This bug is fixed in newer versions of firefox. There seems to be an error in the selection mask size assignment when layer size is greater than image size which can cause the plugin to crash. Intersection of the layer and the active image has been proposed as a solution. Aspect preview code is suggested to be changed by either displaying the entire drawable or just the selection. The fix's milestone is set to 2.4 as it was a crash and should have been resolved before 2.4 release if possible. An example was requested and the same was attached. It was pointed out that channel mixer uses GimpZoomPreview and not GimpAspectPreview & that both had problems when repro of the reporter is followed. Selection mask was found to have width larger than the actual mask in the preview code in the example image. A patch was created which handles layers with offsets and displays area which is the intersection of active area and selection. Selection mask has to be applied for the whole drawable for GimpAspectPreview. A request to commit the patch was made. A suggestion to commit was made. The fix was then committed. If the layer and image have different size, the plug-ins GimpZoomPreview and GimpAspectPreview will fail and can even crash. The bug is hard to fix because some APIs should be changed accordingly. Therefore, although this bug is sever, a patch was designed four years after the bug report. After installing the patch, the area displayed in preview is the intersection between layer and the selected part of an image. For GimpAspectPreview, the selection mask should be applied to the thumbnail of the whole drawable. When an image and a layer have different sizes, plugins can crash because the thumbnails are based on one size only. It is suggested that the intersection between the sizes could be used, or limiting the area appropriately. The problem is bumped several times. An example XCF file is requested and provided to demonstrate the problem. The problem extends to GimpZoomPreview as well as GimpAspectPreview. Work is done to track down where the exact error occurs. A patch is provided which lets GimpZoomPreview handle the layer offsets properly. This is accepted to be committed in the trunk. When rescaling images in GIMP, the interpolation method is not saved from last time it was invoked, which causes inconvenience particularly when users want to repeat rescaling many times. The default method can be chosen in preferences dialog, but it might be hard to find or inconvenient to access. A \"save last setting\" option in the dialog box is suggested but declined because of making a mess in UI. Finally, the last method used is automatically saved and defaulted in the next usage. When rescaling images, GIMP always defaults to a single scaling method defined in the preferences (linear scaling by default) instead of keeping track of the last choice made by the user. GIMP has been updated to remember the scaling settings across dialog invocations. It is suggested to save the last setting used for image scaling so a user doesn't have to change it every time. It is then suggested that this behavior should apply to other dialog options, otherwise users would have to discover the default setting in the preferences. This enhancement is applied, as adding \"save as default\" buttons in dialogs would add clutter. This thread is about a bug in GIMP(GNU Image Manipulation Program) that happens when trying to convert a grayscale image to a black and white image. In this situation, the conversion will take a long time for big images, which is not acceptable due the fact that this conversion is just replacing each 8bit with 1bit Continuing the thread, bug is confirmed but one workaround is suggested (by using Optimal Palette option) which turns out to be a wrong solution and lead to another bug thread. The proposed fix for this bug is to treat the palette as gray rather than rgb which decreases run time by a factor of ten. however this fix only works for grayscale images and rgb image conversion still takes a long time. Apply threshold is fast but converting is quite slow. It is fast if ust the \"Optimal Palette\" option. The converting with \"Optimal Palette\" option is fast but plainly wrong. The \"plainly wrong\" issue is different. A solution was figured out. Patch codes. New problem could appear. The optimal palette does a first workround before determinating to skip both the expensive quantization and dithering stages. The mono palette does not need to care about the pre-workround. The \"mono\" operation is not rare. A \"convert to 1bit\" operation would adjust the internal memory requirements. GIMP's internal memory requirements could not be adjusted significantly. OpenOffice's internal memory requirements could be affected. In GIMP version 2.2.x, converting an image from greyscale to black and white is very slow. An 8bit greyscale image only consists of color values 0 and 255, so converting it to a black and white image should be a very fast operation, replacing 8bit values by 1bit values. There is a workaround, where if you use the \\\"Optimal Palette option\\\" when selecting the \"colormap\", the conversion occurs in a fraction of a second. A fix is committed that gives major speedup when converting greyscale to mono, but the problem still exists for RGB images. This bug discovers the existence of another related bug, and there is a new bug report created for it. This is a defect in GIMP plug-in to capture screenshot- first, there two different entries for same functionality-\"Screen Shot\" and \"Screenshot\", second, there is an option to select region to grab but it does not work. It is explained that the two entries might be there to test two different versions of the program and this is a work in progress. This bug report was submitted to alert developers this functionality is broken but since it is reported on development version, which is expected to have incomplete functionality and hence should not be reported as a bug. There are two similar entries “Screen Shot” and “Screenshot” in the file menu in a development version of GIMP. In addition, when users choose “Screen Shot”, there is no option to “Select a Region to Grab”. However, when the “Screenshot” is selected, a dialogue box will show the option of \"Select a Region to Grab\". Although the option exists, the real functionality has never been implemented at all because of the short of volunteers. Some other software such as Winsnap and IIRC Tor can be used to select a region to grab. Finally a plug-in is added to fix the problems. In the development build of GIMP 2.3.11, the screenshot functionality is incomplete on the windows platform. It is expected that the option to \"Select a Region to Grab\" grabs a certain region of the screen, but instead it takes a screenshot of the whole screen. This is a known issue, and it is stated that the development version has incomplete and broken features, and the user should be using the stable release. It is impossible to implement the look and feel of the X11 screenshot plug-in on the Windows platform, instead Winsnap is used. This is a defect in gnuCash which creates an empty html file while exporting reports with graphs. The current graphical code relies on a library \"Guppi\" (it is no longer maintained), which can print graphs to postscript but cannot export them into HTML. It was decided that bug should be kept as reminder for later release but the problem is not fixed until version 2.2.8. The possible reason looks like gtkhtml doesn't support saving and even it's later version doesn't support inline images, hence fix is only possible using webkit. In the suggested fix gnc-html-webkit pre-parses the HTML string to find <object> tag, calls GOG with the parameter values from the <object> to create a GdkPixbuf, then converts the pixels to png/base64 and embeds the HTML <img> in the original where <object> was. Webkit also handles export by writing that HTML to file. This fix is targeted for version 2.4. GnuCash fails to export reports that contain graphs to HTML, instead creating an empty file. It also fails to make it obvious which formats are supported. This failure is acknowledged, and blamed on the graphing being currently used, which isn't going to change until the gnome2 port is finished. Despite the gnucash-1.8.x series being inactive, the bug report is kept active as a reminder for future work. Two years later, it hasn't been resolved and a request is made to increase the priority of the bug report, which is done. Another two years pass, and possible issues of using GtkHtml and webkit are listed. A follow up concludes that GtkHtml won't work because it doesn't support inline images, and the webkit version will have to be used. GnuCash does not export reports correctly - it always exports as HTML, regardless of the chosen output format, and leaves out images. These problems existed due to limitations of Guppi, the graphical library used in this version of GnuCash. Guppi is only capable of exporting images as PostScript files and does not embed them in HTML. The newer gtkhtml has better HTML support, and webkit supports inline images. This will be fixed in GnuCash version 2.4. When copying/deleting directories from FTP servers in Nautilus, a File Not Error found is given. Many other users experienced this using different FTP server software. It is discovered that the backend should return a G_IO_ERROR_IS_DIRECTORY error, but isn't. The SMB and FTP backends were patched to send the correct error. Nautilus 2.22.0 returns a \"file not available\" error when doing a dnd or deleting a directory on a proftpd served using gvfs. This bug was fixed by implementing a new system for handling 550 error messages. Using gvfs svn and nautilis 2.22.0, copying or deleting a directory leads to a file not available error. This is confirmed by several others, it also occurs in openSUSE with all kinds of FTP servers. The cause is determined to be because of broken backends. Any attempts to open, copy or move a directory should fail with G_IO_ERROR_IS_DIRECTORY, because GIO functions and Nautilus rely on it. The fix is committed, and some changes are made to the implementation before the bug is marked resolved. Possibly from a previous discussion, it was concluded that if struct field is needed for using any widget it should be reported as a bug. This bug report lists 43 examples where this general rule is violated. It was observed that some of these already have accessor functions or occur for deprecated widgets but some of these still need a fix. A suggestion is made that API should be raised to a bit higher level for example to avoid deprecated GtkList to affect Combobox widget. Another suggestion is made to replace list in Combobox with GList. The ongoing work on gseal finally fixes this bug. It is pointed out that some PyGtk wrappers are directly accessing widget data attributes, which shouldn't be needed. A list of 43 examples is provided. Some already have accessor functions, and some are for deprecated widgets. It is suggested that accessor functions be of a higher level, deprecating the existing lower level ones. Applications are already going to break due to deprecated widgets, which has already become a problem for other wrappers. A suggestion is made that access list items as a GList would make everything more usable. The entire problem is handled by a separate development team much later. Struct fields are required for the functionality of a widget as the latest PyGtk wrappers access data members directly and hence C programmers would require to access them too. These struct fields should never be required and hence this is a bug which must be removed by implementing accessor functions. Some of the listed data members which are accessed in the PyGtk wrappers directly already have accessor functions while some of them are for deprecated widgets. The rest require accessor functions. Added to API fix for a future milestone but a higher level for the API is requested as GtkList widget is already deprecated which is required for accessing functionality of the Combo widget. Combo box is already broken in GTK-- where a different implementation for the list is used which makes it impossible to access list data. Hence a suggestion to make the combo a GList is made which would make working with it easier while allowing access to list items. It is not sure if a good way of handling arbitrary widgets with associated text exists without some sort of ListItem. The ongoing gseal work is handling the issues described above. Applications used gnome_help functions to show help files, but gnome_help was part of the deprecated gnome_help. A patch was created to add gtk_show_uri and gtk_show_help to GTK+. A few issues about the patch were raised. It was also suggested to remove gtk_show_help() from the patch. Updated patches were created according to these requests. Another problem was raised that gtk_show_uri allows a NULL parent, but that is not multi-head safe. Updated gtk_show_uri patch was created, using a GdkScreen as input. Some comments were made on this new patch. Updated patch was created according to these comments: GdkScreen can be NULL. The patch was committed and a function that mounts the volume before opening it was left as future work. The gnome_help functions which are currently being used are deprecated, so a patch is offered to switch to gtk_show_uri and gtk_show_help. This is missing updates to a symbol table, has some licensing details wrong, and gtk_show_help doesn't work on all platforms. Updates patches are given which fix these It is pointed out that gtk_show_uri is not multi-head safe due to NULL parent. It is suggested that it be forced to take a parent, but this is rejected. Instead a version which takes GdkScreen is suggested and then provided. It is suggested that GdkScreen should be able to be NULL and that the documentation should be improved, and this is accepted. Auto-mounting is also requested. Someone questions the utility of catering to so many special cases. The patch is accepted. As gnome_help is deprecated, it needs to be replaced by a more general function, gtk_show_uri, according to GNOME goal proposal. Some minor problems (including the version number) are then noticed and fixed in the first patch. This generalization might become problematic as gtk_show_uri can take NULL as the parent widget of help dialogue. Passing a parent could be mandatory, but it would be best if the parent is a screen object not a widget. The parent could now be NULL so as to avoid calling get_screen repeatedly. Adding a flag to mount required space before using it is also discussed. It is said that calling get_screen would be helpful to avoid multi-screen bugs, but since this is rare it will become cumbersome for other cases (say 99% of cases). When running a simple SWT example with the latest version, a Mac user experiences a crash on start up. It is revealed that he must use the -XstartOnFirstThread option when starting SWT applications, or it will crash. This thread is not actually about a bug and is just about a user who could not use SWT library in Mac OS X. It is necessary to use -XstartOnFirstThread option when trying to use SWT library in OS X. Here the user is ignorant of the fact that using this option is necessary, so he gets SIGILL error, the window crashes without anything in the logs. After using this option, no error message is produced. A user is trying to use the latest version of SWT library, but it even fails to run a simple example. The Java compiler version seems to be OK. It might be the way the application is launched on Tiger. It turns out that he needs to add option -XstartOnFirstThread while running it in command line. Some screen reading software is not able to read the group title for controls in dialog boxes. This bug is not reproducible by everyone, and it is determined it only affects WinXP users who have javaw.exe.manifest in jre/bin, as this causes different controls to be used. The problem is fixed in JAWS 6.0. JAWS and Window-Eyes do not show group titles in some UI dialogs (where groups have a single child without a name). Search and find/replace dialogs are introduced as two test cases. Controls could be read again when they get focus or their windows have just got opened. The problem is not seen by some other people. Therefore, they install a fresh version of the software. However, users get different outcomes from fresh versions (both perfect and erroneous). Finally, it turns out that this problem only happens in Win XP when Win2K modules are mistakenly being used. An accessibility concern is raised as both Window-Eyes and JAWS seem to fail to read out the title of groups of radio buttons and other controls. A work-around in Window-Eyes is provided, and specific examples of the failure are listed. Further testing with various versions of JAWS does not show this problem. A stand-alone example applet is given to demonstrate the problem, but again it cannot be reproduced by others. The JAWS configuration files are compared. Finally, the problem is shown to be specific to JAWS on Windows XP with a specific Java environment. This is resolved in the new version 6.0 of JAWS. When Manfred Hahn installed Teneo, a set of plugins, the Ant Preferences page was corrupted. This behavior should not have happened, but no cause or solution is found. A later version of Teneo install correctly, so this issue is considered fixed. Teneo installation results in the the \"Ant Home Entries\" entry on the classpath page being empty, as well as generating NullPointerExceptions in the log file. This is only seen when Teneo is installed and enabled. This behavior is questioned, as there isn't an obvious way for Teneo to affect other plugins like that. A set of log files, screen captures and other information is requested. These are provided. It remains mysterious how Teneo could be causing these problems, and the bug report's classification is changed. The problem isn't seen with the new version of Teneo and the bug is closed. Installation of Teneo causes the entry \"Ant Home Entries(Default)\" to vanish from the preferences page. Null pointer exceptions in the log file and \"Malformed URL\" error on opening preferences page also result. A step by step clean installation of an eclipse environment shows that this problem occurs right after installation of Teneo where disabling Teneo restores things to normal. A request for debug information like screendump and log file using a -clean switch is made to further investigate this problem. The generated log files and related data did not lead to the reason behind this problem. The issue was later resolved with a new release of Teneo which is believed to have done a consolidation of the used libraries. Automatic testing have been failing for the most recent builds, probably due to crashes in BrowserTests. A patch is offered which changes resource pools so they are only released when their device count goes to zero. The patch is pushed back for the next release candidate as it hasn't been tested properly. A simpler patch is offered, which checks the pool validity. The automated testing system is set to start performing the tests which were crashing it again. This thread is about a bug which causes crash in releng platform of eclipse. The bug affects running of SWT test suite and is emerged because of malfunctioning in main thread pool. The reason for crash is that pool was not removed from the thread local dictionary and got reused. One resolving suggestion is to only release the main thread pool when device count goes to zero, but finally the idea for fixing the bug is making sure pool is always valid, so another display will not use a released pool. Browser tests crashes. Comment out crashing tests in RC1. It does not affect the usability. Issue caused by the strategy of releasing pools. New strategy. Should test more. New fix and new problem. An infinite loop is triggered when Lightning attempts to access a calendar that no longer exists, despite receiving a correct 404 result. This problem occured when safeRefresh() was called from within calDavCalendar.js and has been fixed. This report is about a bug in lightning which is a application developed by Mozilla. This bug occurs when a subscribed calendar in lightning is deleted from the server. As a result, in this situation lightning gets stuck in an infinite loop using 100% of CPU, despite the fact that server has sent 404 error. The expected result in this situation is to stop sending requests when 404 error is received. For resolving this bug, after realizing that there exists many connections to the server at the same time, it turns out that the bug is happening when a method named safeRefresh() is called. This bug is fixed after the developers add a condition to safeRefresh() function which check for error 404 and if this error is found, no refresh is done. If a calendar you subscribe to in Thunderbird is later deleted, Thunderbird will go into an infinite loop making HTTP requests to the server. The 404 message is never checked, so it goes into an infinite loop. The bug is then fixed by doing the proper checks. It takes a lot of CPU time to move a folder to another location in the same account when many tmprules-xxx.dat files exit in temp directory. Deleting or renaming a folder cause the same problem. In addition, it takes 10 to 20 percent more CPU time to check emails. The problem can be temporally solved by deleting the 100,00 temp files in the temp folder. However, the temp files will appear gradually and cause the same problem again. In fact, the underline cause for this bug maybe the same as for bug 362539. The patch fixes bug 410739 can fix this bug too. In Thunderbird, dragging and dropping a folder into another, or renaming a folder, causes the CPU usage to jump to over 50%, and takes more than a minute of processing. The bug happens because there are more than 10000 files in the temp folder, called tmprules-xxx.dat. It occurs because Thunderbird tries to parse all 10000 rules files to determine if they need to be updated after the file move. Moving an email folder or subfolder in Thunderbird results in large delays when there are a large number of \"tmprules-N.dat\". Resolved as part of the fix for bug 375292 on branch 1.8 and trunk. This is an enhancement request for Thunderbird email client so that user is able to select multiple folders using shift click and move them at once to another folder. This is a highly desirable feature and is important for migrating heavy users over to Thunderbird from Outlook who have lots of folder to organize. The functionality to select multiple folders is available on latest trunk but on 'drag and drop' only one folder is moved. The proposed fix lists various possible options available on multiple select like- Get Messages, Open, Unsubscribe(for newsgroups), Delete(it is decided that option to delete would be disabled for multiple select because of some technical difficulties), Mark folder/newsgroup read. Some more related issues are also listed like-delete on newsgroup to unsubscribe was broken, save search wasn't enabled for news and tools menu folder commands. Proposed changes are approved and bug is fixed. This thread is about a bug in thunderbird mozilla which occurs when user wants to select multiple folders or mailboxes from the folders pane. when user tries to select another folder by shift+click, previous selection is lost. People have discussed on the importance of this feature for example its benefit for migrated users from outlook. further in the thread it turns out that multiple selection is resolved, but dragging multiple items is not supported. The suggestion for fixing the bug is to make some items enabled for multiple selections, among them are open, delete, compact, mark as read. The bug is fixed by using the suggestion mentioned above, and also some other bugs are found in this thread which was handled by delevopers. The folders pane in Thunderbird does not provide a usable implementation of multi select. Multiple folders can be selected, but once these folders are \"used\" in some way (for example, they are all moved into a different folder), only one folder is actually moved. This is confirmed by several others, and is highly desirable behaviour. The proposed fix applies to many uses of multi select, and is fixed and marked resolved. In KDE4, after using the Alt+Shit+Tab keyboard shortcut, the keyboard becomes nonresponsive. The bug is confirmed by others. The problem is found in KGlobalAccel and fixed. A similar bug is found when using the Alt+Print Screen and Ctrl+Print Screen shortcuts, for the same reason as before. . The new fix is checked in. The bug appears again in KDE 4.2 and it is not clear whether it is fixed in this version. This report is about a bug in KDE which occurs when user presses Alt+shift+tab for switching between keyboard layouts. After pressing this key combination keyboard does not respond any more. It turns out that the problem is in KGlobalAccel which doesn't release the grab when a shortcut is set that isn't triggered and a hot fix is provided to solve the problem. Finally users claim the same bug for combination of alt+printScr which is also fixed by developers. When using Alt+Shift+Tab to switch between applications, the keyboard does not respond anymore. However, the mouse still works. The problem is caused by KGlobalAccel because it does not release the grab when a shortcut is set yet un-triggered. Some other shortcuts may also cause this problem, e.g. Alt+Print. In fact, one can check if two shortcuts cause the same problem by comparing the label of one shortcut button after pressing it with the label of another shortcut in the rc-file. However, although a patch is added, it seems that the same problem still exists in KDE 4.2 and KDE 4.2 Beta 2. KDevelop's feature to find callers of functions does not work. If it did work, it would not do a good job for a number of reasons. It is suggested that the author of the bug upgrade from version 2 of KDevelop, which is no longer under development, to version 3. It is stated that version 3 has fixed many bugs, but it is unclear whether this fixed the bug at hand or not. This thread is about adding one functionality to KDE which allows users to find places in the code that a function is called. In KDE 2 users can use 'grep' but it has some limitations such as ignoring overloaded functions and white space at the end of function name. It turns out that KDE 3 also does not have such feature, but there is a suggestion of using regular expressions to handle this functionality some suggestion for adding highlight feature and adding shortcut keys for finding caller of functions is made. Last suggestion is having a 'function call tree' or 'call graph'. Finally this functionally is added in KDE 4. Find callers of functions does not work properly. Problem reported in ver 2.1.3. Suggest to upgrade to ver 3. KDE3 can open KDE2 projects and both of them can run on the same PC. FTP to download KDE3 KDE3 is good and wait for stable ver. Issue still exists. Expected feature is similar to Find Usage in IntelliJ IDEA. Highlight Usage is in wishlist. Suggested behaviour. Function Call Tree view is in wishlist The feature is not clever enough. Highlight of usage of variables has been implemented in KDE4. This a defect related to GUI of Amarok music player which bottom bar for managing player covers parts of other applets sometimes. A suggestion is made that it should appear/disappear on mouse over, however the real solution would be to make it not cover applet. Bottom bar should be like panel in KDE which does not cover a window by default and applet should not be larger than viewing area whether it is resizable or not. In other words, there should be not part of applet which is inaccessible. There was some discussion debating whether this is a defect or non-completed feature. The bug is finally fixed. In the anarok2-svn contextview the bottom bar sometimes obscures applet content. Applets should not be larger than the viewable area, and should be given an appropriate sizehint. This bug was fixed in 2.1.1. The bottom bar for managing applets sometimes covers the applets, obscuring the bottom part. Some think it could be only displaying on mouseover, but it is decided applets should never be drawn underneath. This bug is caused by the incomplete feature of resizing applets, and will be fixed when that feature is completed. A few months later the bug is fixed. Wishlist to turn off the displaying of contact messneger online status. Opposite option to display +CSS. No technical issue but time consuming. It could be complicated. Current contract list codes are flexible Agree to disable it. Bug is fixed. An initial request for hiding the contact network icons in Kopete was made as to the reporter it didn't matter and was causing unnecessary clutter. Another person made a request for an opposite setting in which the contacts are sorted by their networks. It was suggested that a customization using CSS could be provided. It was also pointed out that KHTML widget could be used for the customization. It was then suggested that many people might be interested in showing the contact networks and if there's enough demand then an option to disable it can be implemented. A fix was made in trunk where the user can define the list layout and also icons can be hidden if required. This is an enhancement request related to Kopete which will allow user to turn off displaying irc icon next to the display name. There is another request to allow removing KopeteStatusIcon from the contact list details and a more general solution would be to allow CSS customization of the contact list. This functionality can be achieved without any technical hurdles by rendering the list view inside a KHTML widget but it may not be done before KDE 3.4. Contact list code is flexible enough to allow addition of a drag-and-drop style editor for this change. The change is finally made so that a user can define contact list layout to hide/show an icon or change order. When using shortcut CTRL+I to align codes, the line below will always move right for Kate. But sometimes, we expect the line below moves left to align this line with the above line. However, Kate does not have this feature. To move the line below left, one can select the ‘Unindent’ or ‘Clean Indentation’ options. This feature do exist in CVS. In CVS, lines are aligned according to normal C/C++ styles. At last, empty lines are ignored when align documents since the empty lines may introduce many useless leading spaces or make the alignment of documents very slow. This is a defect related to code indentation in Kate. Current line of text is not align as expected in the code on pressing ctrl-i and all it does is moves to the next tab stop. It is later clarified that Kate always inserts positive indent to a line on ctrl-i rather than formatting the code, so it is an expected behavior. However, this functionality of formatting code is available in CVS which aligns code(current line or block of text) in right formatting for C/C++ on pressing CTRL+TAB. It is tested if it shows same behavior on an example as it does on emacs. It works almost perfectly apart from some deviations like- closing parenthesis are not aligned with the opening one and this can be filed as a new enhancement request. It also does not work on empty lines which is intentional because it would leave useless leading space and also make formatting slower for the whole document. A bug for indentation was filed which was later reported to be a new feature rather than a bug. The report was made about out of indentation phrases which should be aligned with the line above it rather than the positive indentation scheme followed by kate. The requested behaviour was that of align section in which the entire section selected gets aligned with respect to itself. A suggestion to try using 'Clean Indentation' was made for aligning misaligned blocks. This requirement was then found to be present in the cvs which did the alignment of the current line or the selected text using normal c/c++ conventions. It was found to work for expression in parenthesis but for arguments it was found to work with limited correctness. A suggestion to open another wishlist was made if this was a problem. It was pointed out that if there's no text in a line then it's not aligned which was later reported to be a feature. This is a feature enhancement request to include a swap button to change selection in photo from landscape to portrait. There is a suggestion to keep it for next version but it possibly can be implemented as part of version 2.4. A suggestion was made to use mouse to make selection and choose landscape or portrait selection based on the shape of the selection, if it is closer to landscape or portrait and it can save adding another button to UI. However, it is argued that this enhancement is different from suggested above, the use case can be described as fixing the aspect ratio in one view, then resizing the box so that it can rotate and then rotating it by 90 degrees. It is emphasized that the above suggestion of using mouse makes sense and can be useful to select region initially, however a toggle button is still required. Also, if mouse is only way to change selection from landscape to portrait, there is no way for user to discover that this feature exist. The enhancement is implemented and tested. An enhancement feature has been request here which swaps the aspect ratio of the selection box between landscape and potrait. A different input scheme was suggested in which the user draws a selection box and depending on the dimensions it is snapped to either a landscape or potrait aspect ratio (Albert). But since the aspect ratio swap was required by the reporter after the selection box has been drawn this idea wasn't carried forward although the idea seemed pertinent and useful. For a swap button it was also suggested to use the first point of the selection box as a pivot for flipping. Also it was suggested that initial aspect ratio could be set to that of the image. A toggle button for setting the initial aspect ratio from the image, previous selection or the scheme suggested by Albert could be implemented. However it was stated that making the output depend on user's mouse action is not discoverable and hence the user wouldn't be able to find out how to swap. This is a request for a new button that swaps between x and 1/x (portrait/landscape) orientation of selection rectangles in GIMP. The use case scenario is one where the user selects and entire image and scales the selection rectangle to maintain the aspect ratio, but then wishes to switch from portrait to landscape orientation or vice versa. This feature was implemented in trunk. It was requested to provide some productivity features, e.g., extensible hyperlink support, etc and improve the current search/replace dialog. A few other issues associated with text editor were raised, too, including the ctrl-backspace problem and support for multiline text For the search/replace dialog, there would be minimal improvements, but not a complete redesign. . For the ctrl-backspace problem, it was suggested to file a separate bug report. . For extensible hyperlink support, some people preferred it to be much lower. This is an enhancement request which talks about miscellaneous productivity features that should be added for example- triple-click, extensible hyperlink support and spell checking. There is also a requirement to improve search/replace dialog, however that would be limited to minimal improvements like being able to resize it. The other things to look at include-support for searching multiline text and improving usability of search dialog. There were concerns about keeping extensive hyperlink support to minimal as it is not as important for porting UIForms from FormText to StyledText, however that discussion also need to be moved to other threads. There are also some requests about text editor widgets but they need to be filed as separate bugs. The bug has been closed but there is no discussion about the changes made. An enhancement request for adding support for text-editor improvements in selecting, spell checking, searching and hyperlinking text has been made. A suggestion for improving the current search/replace dialog has also been made. Few improvements which can be made have been pointed out like Ctrl-Backspace doesn't work in all editors, searching multiline text etc. The problem of Ctrl-Backspace not working in all editors was reported to be solvable by pushing the behaviour of TextFieldNavigationHandler down to Platform Text. since JFace doesn't depend on text editor plug-ins it can't adopt those. Also a request for making the support for hyperlink much lower was made because UI Forms would like to port from Formtext to StyledText bearing in mind the keyfeatures additions in StyledText. Also support for Return key in 2 ways for multiline textboxes like Run-Arguments has been made to handle adding CR/LF to the current text box and to send return key to the parent dialog. The request bug was marked as fixed with a new version release. This is an enhancement request for making a separate window for history in Firefox and not relying on sidebar(ctrl-h). There is some disagreement about need for this enhancement. A suggestion is made to make an about page for history similar to about:config, which can complement the sidebar and a new separate history window would probably be an overkill. \"chrome://browser/content/history/history-panel.xul\" can also be used to show history information in a separate window. There is another request to make history more detailed for example providing information like title, location & last visited and also making this functionality as easily accessible as sidebar. A general observation is made that Mozilla history page was better and Firefox does not support a decent history functionality. However, there is an extension to Firefox(EHM, Enhanced History Manager) that solves the problem nicely. A bug was reported that using the file browser, a file when copying or moving it onto itself was deleted. A patch for this was provided, but it was incorrect. A semi correct patch tried to compare the KURLs are identical before attempting to copy. The workflow of how the removing happened was discussed. Another bug was raised that slotCopyOperationFinished gets called independently of slotJobFinished. A patch was created to fix these problems. When one uses the file browser to navigate to a song in the collection and select “move to collection”, and at the same time ensure that the new file name is the same as the old file name, the song is renamed to itself, then deleted. The cause of this bug is that CollectionLocation removes the source files after the copying operation. An patch is added to prevent this problem by making sure that the source and destination are different before moving and removing files. If a song is moved from a file browser to a song collection where one with a same name exists then the song gets deleted. A patch was made which checks for the song to be present in the collection before removing it after the move operation but was found to be incorrect. Another patch was then made which checks for the KURLs to be identical before copying which was later modified to include cleaned URLs. It was pointed out that problem with same src and dest wasn't the one which was causing this behavior but it's that since the file is being moved from a file browser, a special code which checks source collection doesn't get called. It was then pointed out by the initial patch maker that the removal code is never called and it's moving a file to itself which is deleting the file. slotJobFinished is not called in the current form which results in slotCopyOperationFinished in not being called and hence removal code in not being called. A patch was then created where slotCopyOperationFinished is called when there are no jobs created which resolved the problem. This is a defect related to Konsole where ctrl+c does not stop an background process. It is surprising that this bug is dependent on the process currently running on Konsole(for example it works for strace but not for ruby). It is discovered and confirmed later that bug was introduced in revision 760614. Bug sometimes disappear when user types something(cursor becomes filled), but this does not happen always. It was suggested that Session::sendSignal() may have the problem but it is realized that it is only called at the end of the terminal session to kill the main shell process. Another change was suggested in function void Pty::lockPty(bool lock), but this function is called when Ctrl+S or Ctrl+Q is pressed. Changing interrupt key from ctrl+c to ctrl+y also does not solve the problem. It was discovered that problem disappears in two scenarios, first running \"konsole --nofork\" and second starting Konsole normally (with no arguments), then attach to it with strace (using strace -ttt -p ). Problem is finally fixed by resetting all signal handlers to the default (SIG_DFL) in the child process after forking. A bug appeared in Konsole such that using ctrl+c does not break the current command. Many other users reproduce this bug, except for it not affecting a few application. The problem is gone when running with the --nofork command, or attaching to strace. The bug is then fixed. Pressing Control+C from within the KDE 2.1 Konsole doesn't terminate the process. This issue was fixed by resetting all signal handlers to the default (SIG_DFL) in the child process after forking, SVN commit #771570. Problems with the zoom out view were reported: adding activity focused view on the new activity until zoom level changed, and dragging around the view didn't work right after adding an activity. Some people thought add activity option (and zoom out) should be removed in the 4.1 final, but other people didn't agree. . One fix of dragging the view around was suggested. When a new activity is added, only the new activity is shown. After rooming in then rooming out, both activities can be shown. However, dragging around the old activity does not work, the place of the old activity jump to another place, and the place of the new activity seems arbitrary. In addition, switching activity also makes the view jump suddenly to another place. Since the operations of adding activity and rooming out are useful, the above problems should be solved. There is a problem with the zoom out view which jumps around to focus on the new added activity and throws the rest out of focus. Also adding a new activity makes drag and drop to move the view to other activities unusable. Zooming in and the zooming out makes the last activity and the currently added activity visible. For showing 3 added activities the processes of zooming in and out has to be repeated twice. Also the order in which the activities is added is not maintained during this process along with the layout being messed up. The offset of the activity overview changes when double clicked on the first activity. The performance when zooming out has also been reported to be very slow for some users. But at the same time people using nvidia have reported a decent performance. The issue was resolved by making the view not move more than necessary to show the newly added activity, which also fixed the issue with dragging the view around. This is a defect related to Amarok music player on KDE. Application crashes when trying to move a large number of files to a collection because of large number of file dialogs opened even on powerful machine. A suggestion is made to either make transfer sequential or not displaying a file dialog. The bug is hard to reproduce on different machines and requires very specific option ticked on in \"Organize Files\" option. There is a problem with boolean logic which caused the progress info to be shown when overwriting tracks during a collection copy and this modification fixes the bug. Moving files within Amarok inappropriately causes a dialog to be opened for each file under certain conditions. The following options must be selected to reproduce the behaviour: (1) Ignore \"the\" in artist names, (2) Group by file type, (3) Replace spaces with underscores/restrict to ASCII, (4) VFAT safe filenames, (5) Overwrite destination. A bug fix was added whereby boolean logic was corrected to avoid showing progress info when overwriting tracks during a collection copy. When using Amarok to move files into a music collection, a file dialog is opened for every file, which in this case was 16,000 file, and crashed the machine. There was trouble reproducing the bug, until it is figured out that the \"Overwrite destination\" option was causing the bug. The faulty logic that caused this bug is now fixed.