Totem crashes when trying to use the ’open file’ dialog to navigate to a certain subdirectory (containing only two subdirectories). This happens with 99% certainty. In the remaining 1% it happens when I proceed to one of the two sub-subdirectories. Unlike bug #891460, this is on an ext4 partition.
Then I would rephrase this into a bug report as follows: currently, the toolbar navigational buttons (previous, next) are positioned to the right from the location bar. This is inconsistent with what most users probably expect, which is the way they are located in a web browser.
The three web browsers I currently have installed on this system position these elements as follows:
From my personal anecdotal evidence, with this background, I say suddenly finding the navigational buttons from the right end of the location bar in one app is undly arduous. Thus this bug’s title should be: Move the navigation buttons to the left of the location bar.
(IIRC this was also how the buttons were back in Gnome 2. If there was some usability reasoning behind moving them to the right, I’d be interested in reading about it.)
Bug still present in Precise.
What steps will reproduce the problem?
1. Have a touchscreenless phone
2. Run touchcomic, open comic, zoom in
3. Try panning horizontally
What is the expected output? What do you see instead?
Without touchscreen there’s no way to pan horizontally: though the ’up’ and ’down’ keys do pan vertically, the ’left’ and ’right’ keys navigate between pages.
What version of the product are you using? On what operating system?
TouchComic V1.81 on S60 3rd FP2 (on a Nokia 6220 Classic)
Please provide any additional information below.
I know it’s contrary to the app’s name, but it’d be awesome to be able to use it on this phone too. The number keys don’t seem to do anything; how about utilizing them for simulating panning via touchscreen?
In a case such as Sergey’s, where the problem is caused by a faulty vfat rather than some weirdness on Ubuntu’s side, formatting the disk may be avoided by using fsck:
$ sudo fsck.vfat -r /dev/sdg1 # replace sdg1 with your usb drive partition device file
Aldo and uaneme, your issue looks more like bug #676828 (which I too have in 10.04).
What steps will reproduce the problem?
1. Open http://www.jamendo.com/en/track/696555
2. Click ’Play’
What is the expected output? What do you see instead?
The player (on the right column) loads and begins playing, with a Like button under other sharing options. I’d expect the button not to be there as I’m using FB Disconnect.
What version of the product are you using? On what operating system?
FB Disconnect 1.0.2 in Chromium 13.0.782.218 (build 98754 Linux), Ubuntu 10.04.
Please provide any additional information below.
FB Disconnect does block one Like button, the one below the artist’s name, from showing up on the page.
According to my understanding and based on what Jonas wrote above and also [1], doing the freeze post-BIOS would be useless securitywise; it’s not even a workaround, as any malicious software then just inserts itself into the MBR. This really needs to be fixed at the BIOS level to be effective at all.
[1] http://www.coreboot.org/pipermail/coreboot/2005-May/011688.html
I couldn’t, and neither could I with a 10.10 live, so it’s possibly something that’s changed going from 10.04 to 10.10. I also tried Chromium and Firefox 6 under 10.04; with Firefox 6 the issue persists, whereas with Chromium I can’t reproduce it. There’s of course a more serious bug underlying the browser, as no application issue should bring the entire system to its knees.
(I just realized I used amd64 live discs in the tests whereas the installed 10.04 is an x86 system. Perhaps it makes no difference but I’ll leave judging that to experts.)
I’ll gladly execute more tests if anyone has ideas how to narrow this down even more.
Chrome Version : 13.0.782.218
OS Version: Ubuntu 10.04
URLs (if applicable) :http://mummila.net/varasto/websivut/chromium-middle-click-bug-2011-09-21.html
Other browsers tested:Chromium 15.0.871.0
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:OK
IE 7/8/9:
What steps will reproduce the problem?
1.Middle-click anchor link pointing to an anchor on current page.
2.Repeat step 1.
What is the expected result?
Have two new tabs open with the current page loaded in them and scrolled to selected anchor.
What happens instead?
Only one new tab with the current page opens. Subsequent middle-clicks also fail to bring up new tabs entirely.
Please provide any additional information below. Attach a screenshot if
possible.
The behavior of middle-clicking the anchor can be ’reset’ to work again by middle-clicking another link; after that you can again get one new tab from the first link, but again subsequent middle-clicks fail to bring up any more.
The issue is demonstrated on the page pointed to by the attached URL.
UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/10.04 Chromium/13.0.782.218 Chrome/13.0.782.218 Safari/535.1