Summary: | Exception thrown when opening a <select> pop-up that uses a web font | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eddy Nigg <eddy_nigg> | ||||||||||
Component: | Forms | Assignee: | Nobody <webkit-unassigned> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | ap, ddkilzer, mitz, vicki | ||||||||||
Priority: | P2 | Keywords: | HasReduction, InRadar | ||||||||||
Version: | 525.x (Safari 3.2) | ||||||||||||
Hardware: | Mac | ||||||||||||
OS: | OS X 10.5 | ||||||||||||
URL: | https://www.startssl.com/?app=12 | ||||||||||||
Attachments: |
|
Description
Eddy Nigg
2009-02-11 18:03:38 PST
Is there any resolution coming for this bug or is there a known workaround for the JavaScript code? The JavaScript from comment 0 works with all browsers except Safari. I'm trying to have this bug somehow moved forward. If anything is need in order to help, please ping me. One thing that could help is a reduction - a self-contained short example that shows the problem in action. Thanks for following up. The example can be seen at https://www.startssl.com/?app=11&action=regform The code used is exactly as in comment 0 in particular: stateElement.options[i]=new Option(states[i], states[i], false, false); or a bit clearer: element.options[1]=new Option(stringLabel, stringValue, false, false); Incidentally I'm reading again through some JavaScript specs and it appears to me that the last false value might not be compatible (with some versions). Trying that right now... I was talking about a reduced test case - a dozen lines or so of code total.
That's of course not a requirement for filing a bug, I only suggested that because you specifically asked how you could help.
> Incidentally I'm reading again through some JavaScript specs and it appears to
> me that the last false value might not be compatible (with some versions).
If that works in both IE and Firefox, we should strongly consider making it work in WebKit.
I tried right now with new Option(stringLabel, stringValue, false); and it doesn't work either with Safari. Some more information with this, which could be another issue: The SELECT fields have onchange="doSomething();" as well. Could this be the problem? (In reply to comment #6) > I was talking about a reduced test case - a dozen lines or so of code total. > > That's of course not a requirement for filing a bug, I only suggested that > because you specifically asked how you could help. Thank you, I understand...but doesn't the page source help? See https://www.startssl.com/?app=11&action=regform in particular line 367 and 868 with: <select name="Country" onchange="x_get_states_by_country_name(this.value,changeState); x_get_phonecode_by_country_name(this.value,changePhoneCode);"> Not sure how much time I'd need to produce a test case mimicking the same behaviour... :S I'm now almost 100% certain that the cause for this behavior is the ONCHANGE in the SELECT field. Other SELECT fields which have onchange="doSomething();" lock up as well - without relation to the new Option() function. This still occurs. The "Register" link is now "Sign-up" apparently. This issue is also mentioned on an Ars Technica article now: <http://arstechnica.com/security/news/2009/12/how-to-get-set-with-a-secure-sertificate-for-free.ars> Created attachment 46180 [details]
Test Case For onChange Functionality
I ran into this bug on their web site and their web developer pointed me to this bug report. I knocked up a test case that makes an attempt to recreate this issue with ONLY an onChange and AJAX request. I cannot duplicate the behavior, so I don't think that whatever is happening on that site is related to onChange.
There is a lot of document fiddling happening onLoad and otherwise, though - and something is preventing the popup menus from even being activated. Something else is going on here.
I've included as attachments my test case showing that XHR and onChange on a select element work fine.
Created attachment 46181 [details]
Response for test case
Put this next to the HTML test case - it functions as the AJAX response.
Created attachment 46287 [details]
test case
You may need to click the menu a couple of times before the problem reproduces with this test case.
This is caused by having an online @font-face for menu item text. #0 0x94bf6dd4 in +[NSException raise:format:] () #1 0x9625b1f8 in -[NSCFDictionary setObject:forKey:] () #2 0x058f8ab3 in WebCore::PopupMenu::populate (this=0x1f8a6f60) at /Users/ap/Safari/OpenSource/WebCore/platform/mac/PopupMenuMac.mm:85 #3 0x058f8d03 in WebCore::PopupMenu::show (this=0x1f8a6f60, r=@0xbfffebb0, v=0xa904000, index=0) at /Users/ap/Safari/OpenSource/WebCore/platform/mac/PopupMenuMac.mm:107 #4 0x059ac7c2 in WebCore::RenderMenuList::showPopup (this=0x1f8a76bc) at /Users/ap/Safari/OpenSource/WebCore/rendering/RenderMenuList.cpp:290 #5 0x05a620af in WebCore::SelectElement::menuListDefaultEventHandler (data=@0x1f8a6a3c, element=0x1f8a69f0, event=0x203f4a60, htmlForm=0x0) at /Users/ap/Safari/OpenSource/WebCore/dom/SelectElement.cpp:660 Hallelujah! That's easy to work around for us and hopefully there will be a solution for WebKit based browsers soon. Created attachment 47052 [details]
Use the system font for the pop-up if an NSFont cannot be obtained
I tried to use the CTFontRef (which can be obtained for custom fonts), as it is toll-free bridged with NSFont, however the pop-up just used the system font. This will take care of the exception for now.
Comment on attachment 47052 [details] Use the system font for the pop-up if an NSFont cannot be obtained > + font = style.font().weight() < FontWeightBold ? [NSFont systemFontOfSize:size] :[NSFont boldSystemFontOfSize:size]; Need a space after the : but before [NSFont]. Thanks to all for working on this. |