Site Navigation

Home | Welcome | FAQ | Submit a bug | Site Feedback |
Showing posts with label Chrome. Show all posts
Showing posts with label Chrome. Show all posts

Tuesday, September 7, 2010

bug 387 - setAttribute('type','file'); fails in Chrome & Safari

Issue: #387
Affects: IE6, IE7, IE8, IE9 Beta, Chrome 5,6,7, Safari 5
Fixed In: IE9 Platform Preview 6 (only when rendering in IE9 Standards Document Mode)

We've long known that IE has problems with both setAttribute (bug 242), and specifically changing the type attribute (bug 237) however it looks like it is Chrome and Safari that have an issue now.

It seems that in Chrome and Safari you can't set an input element's type attribute to "file". Try it out below! (It will fail in IE too of course, but that's a known issue)

Example:
filename:





Known Workarounds: None.



Related Issues: None.Bug/Site Feedback | Submit a bug
Posted by xyz at 9:17 AM 0 comments
Labels: , , , , ,

Saturday, August 22, 2009

Bug or Feature? - Round Five

Round Five Getting funky with the Cheez whiz!

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's today's "Bug or Feature"?

Synopsis:
Everyone knows the basic form elements [button|fieldset|input|textarea|select]. Within the [input] element there are several types: [button|checkbox|file|hidden|image|password|radio|reset|submit|text].

However there is a quirk/loophole/bug/feature with the <input> element that some browsers are taking advantage of.

By default, if you don't specify the type attribute, or specify a value that isn't recognized as one of the above types the browser should default to "text" (and every browser does) - however some browsers take advantage of certain key types and then render the field in their own special ways.

For example if you use: <input type="search" value="Keywords..."/> in Safari and Chrome it will render like this:



As you can see a little 'x' is provided automatically to allow users to clear the value with a mouse click.

If you don't specify a value Safari will provide a faded tip in the box indicating what the field is for:



Ok, what about other types? and other browsers?

For example if you use: <input type="email"/> in Opera it will render like this:



The little email icon helps identify the field as being a field expecting an email address as the input value and it also increases the default size of ~20 characters to ~25characters (depending on your font selection)

If you use: <input type="url"/> in Opera it will render like this:



Again Opera adds a little icon and increases the field size to ~28 characters.

Know of any other values for type that one or more browsers treat in a special way? If so, let us know!


So now the Question is...

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.


Update: 100 bonus points for Rafael! As noted in the comments below the "url" and "email" types that Opera rendered uniquely just happen to be 2 of the types specified in Web Forms 2.0 and they happened to be 2 of the less decorated fields. The full set of new field types is supported in Opera and they look and work great! We'll post some screen shots of these fields shortly.



Opera's Web Forms 2.0

Date:



DateTime (local):



DateTime:



Time:



Month:



Week:



Number:



Range: (numbers added for visual aid only)







Bug/Site Feedback |
Submit a bug
Posted by xyz at 5:28 PM 6 comments
Labels: , , ,

Wednesday, August 12, 2009

bug 179 - .innerHTML love outside the body is hit and miss

Issue: #179
Affects: IE6, IE7, IE8, Safari 4, Chrome 2

As most developers know, setting the .innerHTML of an element is one of the fastest ways to dynamically set the content of an element. However there are a few issues when setting the .innerHTML on some elements in some browsers.

For example trying to set the .innerHTML on a [Table, THead, TFoot, TBody, TR] in IE it will fail as will trying to set it on a Select, Pre, or even a (Div with overflow:auto).

Thinking outside the <body> tag, there's a few more tags that you might want to set the .innerHTML on.

The <html>, <head>, <title> tags. Now we can argue that the title tag doesn't accept HTML, but well, we'll let the results speak for themselves.

<html>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Works
Chrome: Works
Opera: Works

<head>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works (Partially) resets the title but doesn't update styles or scripts

<title>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works



Known Workarounds: Use DOM methods to update the content of various tags, and document.title to reset the title value. Just keep in mind that there are other bugs with setting the contents of the script tag, and style tag in IE.


Related Issues: None.


Bug/Site Feedback |
Submit a bug
Posted by xyz at 6:22 AM
Labels: , , , , , ,

Thursday, April 30, 2009

bug 436 - Google Chrome alert() eats your content

Issue: #436
Affects: Google Chrome 1, Google Chrome 2
Fixed in: Google Chrome 5 (possibly earlier, please inform us if you know the exact version)

This particular bug took some time to figure out as it only happens under certain circumstances.

The JavaScript window.alert() function in Chrome will eat (truncate) some of your message if your content meets the following criteria.

If one of the lines in your multi-line message contains 40 or more characters without spaces.

Example:

<script type="text/javascript">
  var msg = 'You can not see the secret word in Google Chrome!\n';
  msg += '=========================================\n';
  msg += 'The Secret word is: Bamboozled!';
  alert(msg);
</script>


You don't believe me, do you? I wouldn't either... so here, try it!



In other browsers you get the secret word, but in Chrome its gone!

Well it gets even more interesting...

So here's what we've found so far:

  • The line after the line with 40+ non-space characters doesn't render

  • Any text beyond the 40+ non-space characters on the same line also doesn't render

  • A Blank line is rendered after the 40+ non-space characters line

  • The content 2 lines after the 40+ non-space characters line DOES render just fine





Known Workarounds: None.


Related Issues: None.


Bug/Site Feedback |
Submit a bug
Posted by xyz at 5:23 AM
Labels: , , , , ,

Thursday, February 26, 2009

bug 487 - onclick/onfocus bugs on select elements in IE, Chrome & Safari

Issue: #487
Fully Affects: IE6, IE7, IE8, IE9, IE10
Partially Affects: Chrome, Safari

The select form control is great for providing options for a user to select from. You can "enforce" validation simply by what you allow for selection, and the control itself is quite keyboard/mouse friendly with a predictable behavior across all browsers.

Well not quite. IE has a bug with setting an onclick or onfocus event handler on a select element in that if any changes are made to the child options of the select, the first attempt to open the select list with the mouse will fail.

It doesn't matter if you are dynamically populating the selects' options from a JavaScript array or an AJAX request, or removing options that are no longer valid.

In Chrome, the onfocus event works just fine, but the onclick event, won't alter the select field's options until the list is collapsed (e.g. when it closes).

In Safari 4 Beta (need to confirm for Safari 3.x), the onfocus event works fine just like Chrome, but the onclick event never alters the options list at all, no matter how many times it is clicked on.

Try the following samples out, both will not let you open the select list on the first click in IE, and the onclick list will behave oddly in Chrome/Safari. (For this test, we are simply cropping the length of the list) both lists originally have options 100,200,300,400,500,600.

Example:
OnClick Test:


OnFoucs Test:


Known Workarounds: One partial fix would be to use the onmousedown event instead of the onclick event, this will fix the IE issue, but only for mouse interaction. Keep in mind that due to (bug 280) there may be significant challenges creating a workaround for this bug.



Related Issues: (bug 280).


Bug/Site Feedback |
Submit a bug
Posted by xyz at 5:18 AM
Labels: , , , , , , ,

Friday, November 28, 2008

bug 471 - font-weight:600 stretches text in IE

Issue: #471
Affects: IE6, IE7, IE8 Beta 1, IE8 Beta 2, Chrome 5,6,7
Fixed In: IE8 PR 1

Update: This apparently affects Google Chrome now (v5,6,7)


When styling text on your site there are several options for bolding. You can use the classic <b> tag, the <strong> tag, or any tag with styling set for the font-weight.

Example:

<style type="text/css">
  .example1{
    font-weight:bold;
  }
  .example2{
    font-weight:700;
  }
  .example3{
    font-weight:??;
    /*normal|bold|bolder|lighter|100|200|300|400|500|600|700|800|900|inherit*/
  }
</style>


Every option works as intended with the exception of 600 in IE. IE will render any text with a font-weight:600 about 10% wider than normal text (regardless if ClearType is turned on or off).


The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@500)



The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@600)



The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@700)


Note: Updated the style to a fixed-width font to better illustrate.



Known Workarounds: None.


Related Issues: None.


Bug/Site Feedback |
Submit a bug
Posted by xyz at 3:06 AM
Labels: , , , , , , ,

Wednesday, November 26, 2008

Google Chrome gets Updated!

Google Chrome: Gets Updated

Just in case you didn't notice, Google has updated their browser from:

AppleWebKit 525.13
to
AppleWebKit 525.19

As a result some of the navigator properties have changed including the vendor!

Was:
Apple Computer, Inc.


Now is:
Google Inc.




Bug/Site Feedback |
Submit a bug
Posted by xyz at 10:38 AM
Labels:

Tuesday, September 2, 2008

Google Chrome Joins The Modern Browser Party

Welcome Google Chrome

For months if not years rumor had it that Google was cooking up a browser of their own which many dubbed "The gBrowser". Since Google had built a good relationship with the Mozilla foundation it was presumed that they would build it on top of the Mozilla rendering engine "Gecko" but Google has just announced / released the "Google Chrome" Web Browser, based on WebKit, the rendering engine inside Safari and Konqueror.

You can download the beta here for Windows (it will be available for Mac and Linux shortly) in one of 43 languages and give it a test spin yourself.




The interface screams of simplicity yet under the hood contains a lot of great design. The browser is designed to load each tab as its own process in the host Operating System, thus if one site crashes, you need not lose your entire browser and all other sites.

Tabs can be easily dragged, dropped and re-arranged... and best of all you can drag a tab out of the set, and start a new window... or merge one or more tabs back into one window just by dragging it back. (Note to all Web Browser makers, this is how all browsers should work!

Developers will be happy too, since it runs WebKit, its fast and any site that supports Safari 3.1 will work just fine with Google Chrome. Not only that it comes with a Task Manager that reports back how much memory your web site/application is actually using so you can watch your memory management and check for memory leaks.

For end users and developers go download it now and check it out! As for Google, welcome to the Modern Browser party, we're certainly glad to have you... Diversity is the key to the modern web.



Bug/Site Feedback |
Submit a bug
Posted by xyz at 4:21 PM
Labels: , , , , ,

Friday, August 3, 2007

Modern Browsers

Modern Browsers: I expect this to be a moving target, but as of mid-2007 I would only qualify the following as "Modern Browsers". You should expect to see little support, and very few features for browsers not listed here. If your Web Browser is not listed here, it IS time to upgrade.


***IE9 announced at PDC and on the IE Blog

*Safari 4.0 is now out in Beta for Mac and Windows

*Firefox 1.5 is a modern web browser for sure, but with the fast pace of Firefox development, full support for this version has already moved on. If you are using Firefox 1.5 we strongly suggest you upgrade to Firefox 2.x or, if 3.x when it is available.
Posted by xyz at 6:20 PM
Labels: , , , , , , , ,
Subscribe to: Posts (Atom)