Steps to reproduce:
1. Start Chromium with new (temporary) profile
2. Go to chrome://settings/advanced
3. Set Page zoom to 500%
4. For any page with content, open the Elements panel
5. Try to expand/shrink elements
What happens:
With the expanding/shrinking arrowheads zoomed 500%, but with code still at default zoom, it’s extremely difficult to hit the arrowhead in the right spot to expand/shrink elements. Depending on the selected Page zoom level the actual hotspot may even fall completely outside the arrowhead graphic (to the left from it).
What I expect to happen:
For the arrowheads and the code to both follow the Page zoom setting or ignore it, and either way, for the arrowhead graphic to function as the actual hotspot for expanding/shrinking elements.
Not reproducible under Unity 3D.
This is apparently caused by something not in Chromium itself: it’s not reproducible in a VM running Oneiric, with 17.0.963.26 from ppa:chromium-daily/dev nor with Chrome 17.0.96356. It *is* reproducible in Precise with the latter too, but not reproducible with Firefox nor Epiphany. In Precise with Chromium 17, it’s reproducible with a temporary profile and a guest login also.
With Chromium 17, I can no longer drag ’n’ drop tabs to reorganize them in an existing window: the tabs area no longer lets me drop tabs onto it, so each tab I pick up gets a new window when dropped. Dragging the tab from the new window into the old won’t work either (cannot drop the tab into where the tabs area should be).
I had plugged in my phone via USB (as a mass memory device), after which Nautilus and Miro crashed. I was trying to send a report from Miro when this occurred. Other GUI apps running at the time were Synaptic, Chromium and Transmission.
There are lots of reports with this title already, but they are all from pre-11.10 era, and I believe there’s a bot that’ll tell me if this is a duplicate so no harm done if it is.
Henkilökohtainen sisältö -välilehden Synkronointi-osiossa ei ole ”Poista synkronoidut tiedot Googlen hallintapaneelista” -valintaa (Chromium 15 ja 17, Chrome 16).
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:
- Epiphany 3.2.1: previous, next buttons above the left end of location bar.
- Firefox 9.0: previous, next buttons to the left from location bar.
- Chromium 15.0.874.121: previous, next buttons to the left from location bar.
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.)
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
a) Minulta kesti pitkään tottua Firefoxin osoitepalkin logiikkaan sen jälkeen, kun se vaihtui (olikohan versioiden 2 ja 3 välillä, vai jo peräti 1.5:n ja 2:n). Nyt sitten kun olen vaihtanut Chromiumiin, en millään totu sen logiikkaan, vaan törmään koko ajan siihen, ettei odottamani osoite ilmesty osoitepalkin tarjokkaisiin antamistani kirjainvihjeistä. On hassusti nurinkurista, mikäli todella on niin kuin epäilen, että Chromiumin logiikka muistuttaa enemmän Firefoxin aiempaa kuin nykyistä logiikkaa.
For me this seems to be tied with using https (and KB SSL Enforcer): with encryption, switching folder views freezes Reader for up to a minute. When I switch to plain http, everything works as fluently as it used to just a week ago. I’m using Chromium 11.0.696.65 (84435) in Ubuntu 10.04.