[Desktop-packages] [Bug 2000628] Re: The wifi password prompt disappear immediately after showing up on 22.04
For information, I got this bug from a fresh install of 22.04. Also, after a reboot, the prompt works as expected for a while, but I always end up with the bug after a while. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/2000628 Title: The wifi password prompt disappear immediately after showing up on 22.04 Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: Some other people reported this bug [here](https://askubuntu.com/questions/1409433/22-04-cant-input- password-for-wifi) Basically, when you try to log into a network, there is no way to input your password. The only way to reach a visible network seems to be by one of the workarounds: use the "Connect to Hidden Network" option, or directly edit the network config files. It seems like a critical bug to me because it can demotivate new users of Ubuntu and Linux. I joined a screen record of the prompt blinking on screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2000628/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2000628] Re: The wifi password prompt disappear immediately after showing up on 22.04
Thanks so much @brian-murray ! I didn't know how to find out the package responsible for that part! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/2000628 Title: The wifi password prompt disappear immediately after showing up on 22.04 Status in ubuntu-meta package in Ubuntu: New Bug description: Some other people reported this bug [here](https://askubuntu.com/questions/1409433/22-04-cant-input- password-for-wifi) Basically, when you try to log into a network, there is no way to input your password. The only way to reach a visible network seems to be by one of the workarounds: use the "Connect to Hidden Network" option, or directly edit the network config files. It seems like a critical bug to me because it can demotivate new users of Ubuntu and Linux. I joined a screen record of the prompt blinking on screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2000628/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1999207] Re: Error in dead key management of latin keyboards
My app is a React app. It contains an advanced text editor. To develop it we needed to catch the input events made on a contentEditable div to update an internal model. So we need to be aware about any change made to the editor. As the compositionend event is wrong, it generates a difference between our internal model and the current html of the page. I'm not sure about what you mean by an "ibus app". And how composition events are "ibus specific" mechanism? They are event documented in the HTML5 W3C standard : https://w3c.github.io/uievents/#interface- compositionevent Is there something I should do in my app that would enable the correct mechanism? I'm not sure neither about your last question. What would be a desktop where ibus is not present at all? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/1999207 Title: Error in dead key management of latin keyboards Status in gnome-settings-daemon package in Ubuntu: Incomplete Bug description: Composition events are incorrect in Ubuntu 22.04 for latin keyboard I opened an issue at Firefox [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that gives all the details, but they diagnosed a bug in ubuntu-ibus To reproduce the issue, you can go [here](https://developer.mozilla.org/en- US/docs/Web/API/Element/compositionstart_event#result) and type ^+u with a fr+latin9 keayboard configuration. Here is the conclusion on the bug report: Ubuntu-ibus commits dead key sequence with empty string first, then, sends only commit string without "composing" state. The latter behavior is a usual case for inputting non-ASCII characters like Emojis. In this case, browsers need to handle it without composition for compatibility between browsers. Therefore, we cannot represent the composed character insertion as a set of composition events. Anyway, dispatching 2 set of composition events for one dead key sequence may cause trouble in web apps. Therefore, as expected, the first composition should update the "preedit string" to the composed string and commit it simply. The bug was reproduced with installing Ubuntu 22.04 with English locale and adding "French (alt., Latin-9 only)" keyboard layout. And also reproduced with the other Western keyboard layouts which have dead keys. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1999207/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1999207] Re: Error in dead key management of latin keyboards
Ok, I can confirm that it works... It seems weird to me that it works, but it just works. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1999207 Title: Error in dead key management of latin keyboards Status in ibus package in Ubuntu: Incomplete Bug description: Composition events are incorrect in Ubuntu 22.04 for latin keyboard I opened an issue at Firefox [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that gives all the details, but they diagnosed a bug in ubuntu-ibus To reproduce the issue, you can go [here](https://developer.mozilla.org/en- US/docs/Web/API/Element/compositionstart_event#result) and type ^+u with a fr+latin9 keayboard configuration. Here is the conclusion on the bug report: Ubuntu-ibus commits dead key sequence with empty string first, then, sends only commit string without "composing" state. The latter behavior is a usual case for inputting non-ASCII characters like Emojis. In this case, browsers need to handle it without composition for compatibility between browsers. Therefore, we cannot represent the composed character insertion as a set of composition events. Anyway, dispatching 2 set of composition events for one dead key sequence may cause trouble in web apps. Therefore, as expected, the first composition should update the "preedit string" to the composed string and commit it simply. The bug was reproduced with installing Ubuntu 22.04 with English locale and adding "French (alt., Latin-9 only)" keyboard layout. And also reproduced with the other Western keyboard layouts which have dead keys. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1999207/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1999207] Re: Error in dead key management of latin keyboards
Hum... I'm sorry, I might be doing something wrong. I did: `sudo apt install ibus-libpinyin` I restarted the computer I went to Settings => Keyboard, and in "Input sources" I pressed the "+", but there I could only chose between English or French variations. If I press "Others", I just see more English or French alternatives. What am I missing? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1999207 Title: Error in dead key management of latin keyboards Status in ibus package in Ubuntu: Incomplete Bug description: Composition events are incorrect in Ubuntu 22.04 for latin keyboard I opened an issue at Firefox [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that gives all the details, but they diagnosed a bug in ubuntu-ibus To reproduce the issue, you can go [here](https://developer.mozilla.org/en- US/docs/Web/API/Element/compositionstart_event#result) and type ^+u with a fr+latin9 keayboard configuration. Here is the conclusion on the bug report: Ubuntu-ibus commits dead key sequence with empty string first, then, sends only commit string without "composing" state. The latter behavior is a usual case for inputting non-ASCII characters like Emojis. In this case, browsers need to handle it without composition for compatibility between browsers. Therefore, we cannot represent the composed character insertion as a set of composition events. Anyway, dispatching 2 set of composition events for one dead key sequence may cause trouble in web apps. Therefore, as expected, the first composition should update the "preedit string" to the composed string and commit it simply. The bug was reproduced with installing Ubuntu 22.04 with English locale and adding "French (alt., Latin-9 only)" keyboard layout. And also reproduced with the other Western keyboard layouts which have dead keys. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1999207/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1999207] Re: Error in dead key management of latin keyboards
I'm a bit confused about your questions related with xkb-data but I hope
that this will help: here is the result of `setxkbmap -print`:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(azerty)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols { include "pc+fr(latin9)+fr(oss):2+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
And `setxkbmap -query`:
rules: evdev
model: pc105
layout: fr,fr
variant:latin9,oss
About the consequences for users, well, the source of all this is the
breaking of compositionupdate and compositionend events for those users
on Firefox. My app relies on compositionend events, but, as those events
were not created by myself, I guess that my app is not the only program
relying on those events. If those events are not accurate, it will break
any program relying on it.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1999207
Title:
Error in dead key management of latin keyboards
Status in ibus package in Ubuntu:
Incomplete
Bug description:
Composition events are incorrect in Ubuntu 22.04 for latin keyboard
I opened an issue at Firefox
[here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that
gives all the details, but they diagnosed a bug in ubuntu-ibus
To reproduce the issue, you can go
[here](https://developer.mozilla.org/en-
US/docs/Web/API/Element/compositionstart_event#result) and type ^+u
with a fr+latin9 keayboard configuration.
Here is the conclusion on the bug report:
Ubuntu-ibus commits dead key sequence with empty string first, then,
sends only commit string without "composing" state. The latter
behavior is a usual case for inputting non-ASCII characters like
Emojis. In this case, browsers need to handle it without composition
for compatibility between browsers. Therefore, we cannot represent the
composed character insertion as a set of composition events. Anyway,
dispatching 2 set of composition events for one dead key sequence may
cause trouble in web apps. Therefore, as expected, the first
composition should update the "preedit string" to the composed string
and commit it simply.
The bug was reproduced with installing Ubuntu 22.04 with English
locale and adding "French (alt., Latin-9 only)" keyboard layout. And
also reproduced with the other Western keyboard layouts which have
dead keys.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1999207/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1999207] Re: Error in dead key management of latin keyboards
Here is a layout looking almost like mine: https://en.wikipedia.org/wiki/AZERTY#/media/File:KB_France.svg I press the key which is to the right to `p` and to the left of `$ ` and do not need to hold AltGr nor Shift. If you run `gkbd-keyboard-display -l latin-9`, you should see my layout. It doesn't look like what you describe. Don't hesitate if I can help more. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1999207 Title: Error in dead key management of latin keyboards Status in ibus package in Ubuntu: Incomplete Bug description: Composition events are incorrect in Ubuntu 22.04 for latin keyboard I opened an issue at Firefox [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that gives all the details, but they diagnosed a bug in ubuntu-ibus To reproduce the issue, you can go [here](https://developer.mozilla.org/en- US/docs/Web/API/Element/compositionstart_event#result) and type ^+u with a fr+latin9 keayboard configuration. Here is the conclusion on the bug report: Ubuntu-ibus commits dead key sequence with empty string first, then, sends only commit string without "composing" state. The latter behavior is a usual case for inputting non-ASCII characters like Emojis. In this case, browsers need to handle it without composition for compatibility between browsers. Therefore, we cannot represent the composed character insertion as a set of composition events. Anyway, dispatching 2 set of composition events for one dead key sequence may cause trouble in web apps. Therefore, as expected, the first composition should update the "preedit string" to the composed string and commit it simply. The bug was reproduced with installing Ubuntu 22.04 with English locale and adding "French (alt., Latin-9 only)" keyboard layout. And also reproduced with the other Western keyboard layouts which have dead keys. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1999207/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1999207] [NEW] Error in dead key management of latin keyboards
Public bug reported: Composition events are incorrect in Ubuntu 22.04 for latin keyboard I opened an issue at Firefox [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that gives all the details, but they diagnosed a bug in ubuntu-ibus To reproduce the issue, you can go [here](https://developer.mozilla.org/en- US/docs/Web/API/Element/compositionstart_event#result) and type ^+u with a fr+latin9 keayboard configuration. Here is the conclusion on the bug report: Ubuntu-ibus commits dead key sequence with empty string first, then, sends only commit string without "composing" state. The latter behavior is a usual case for inputting non-ASCII characters like Emojis. In this case, browsers need to handle it without composition for compatibility between browsers. Therefore, we cannot represent the composed character insertion as a set of composition events. Anyway, dispatching 2 set of composition events for one dead key sequence may cause trouble in web apps. Therefore, as expected, the first composition should update the "preedit string" to the composed string and commit it simply. The bug was reproduced with installing Ubuntu 22.04 with English locale and adding "French (alt., Latin-9 only)" keyboard layout. And also reproduced with the other Western keyboard layouts which have dead keys. ** Affects: ibus (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1999207 Title: Error in dead key management of latin keyboards Status in ibus package in Ubuntu: New Bug description: Composition events are incorrect in Ubuntu 22.04 for latin keyboard I opened an issue at Firefox [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1802989) that gives all the details, but they diagnosed a bug in ubuntu-ibus To reproduce the issue, you can go [here](https://developer.mozilla.org/en- US/docs/Web/API/Element/compositionstart_event#result) and type ^+u with a fr+latin9 keayboard configuration. Here is the conclusion on the bug report: Ubuntu-ibus commits dead key sequence with empty string first, then, sends only commit string without "composing" state. The latter behavior is a usual case for inputting non-ASCII characters like Emojis. In this case, browsers need to handle it without composition for compatibility between browsers. Therefore, we cannot represent the composed character insertion as a set of composition events. Anyway, dispatching 2 set of composition events for one dead key sequence may cause trouble in web apps. Therefore, as expected, the first composition should update the "preedit string" to the composed string and commit it simply. The bug was reproduced with installing Ubuntu 22.04 with English locale and adding "French (alt., Latin-9 only)" keyboard layout. And also reproduced with the other Western keyboard layouts which have dead keys. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1999207/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1110138] Re: Unity: wrong window dimensions / location in Java applications
I also face the bug. I think that the discussion made at http://stackoverflow.com/questions/30836201/jframe-wrong-location-with- ubuntu-unity can help understand and track the bug. The issue is that the behaviour is random. See my edit to detect when it happens. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1110138 Title: Unity: wrong window dimensions / location in Java applications Status in Compiz: Fix Released Status in Compiz 0.9.9 series: Fix Released Status in Java OpenStreetMap editor: Unknown Status in compiz package in Ubuntu: Fix Released Status in openjdk-7 package in Ubuntu: Confirmed Bug description: In Java applications, the functions to set and get window dimensions and position do not work as expected. This problem is only observed in Unity but not gnome, Win., etc. Details: * Call setSize(200, 200) and setLocation(300,400) for a JDialog object. * If you call getSize() and getLocation() directly after making the JDialog visible, the result will be (200,200) and (300,400). Calling getSize() and getLocation() again, a split second later, the result is now (200,200) and (301,428). In both cases, the values are wrong, the size and location is actually (202,229) and (300,400) as shown by a screen capture. Consequences: * If the dialog is designed to reach to the bottom of the screen, the lower end will be cut off about 30 pixel, so the window needs to be moved by the user each time to see the lower button row (e.g. settings dialog in netbeans on medium resolution screen). * In applications that save and restore window position and size, the window will move down 28 pixel each time it is opened an closed (e.g. JOSM, preference dialog). Expected behavior: * The result of getLocation() should be constant for one window unless the user moves the window * setSize(dx,dy) should not set the size of the content pane, but the size of the entire window, including window decorations * be consistent for all Window objects, e.g. in the attached sample, the JFrame works correctly, but the JDialog shows the described bug Output of the sample code (press button click, then press button click2): dlg.getLocationOnScreen()=java.awt.Point[x=300,y=400] dlg.getLocationOnScreen()=java.awt.Point[x=301,y=428] Note: Both getLocation() and getLocationOnScreen() return the same values. Observed for the following Java versions: java version 1.6.0_24 OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~12.10.1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) and java version 1.7.0_09 OpenJDK Runtime Environment (IcedTea7 2.3.4) (7u9-2.3.4-0ubuntu1.12.10.1) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) Ubuntu 12.10 unity-6.12.0-0ubuntu0.2 update: same behavior in gnome classic with compiz running To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/1110138/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
