336156 - Domino Web Access 7 - the Ambiguous Name dialog does not populate the To: field.

Status: RESOLVED WONTFIX

(Camino Graveyard :: Page Layout, defect)

Description

[Scott]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20060430 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20060430 Camino/1.0+

Build: 2006043001 (1.0+)
Domino 7 Access now works in FireFox and Camino (beta server).  One issue that works in Firefox 1.5.02 but not the latest build of Camino is that if you type a partial name in the T0: field of a message, and click send, and Ambiguous name dialog will appear with all of the matches to that partial name.

In Firefox 1.5.02 this appears as a Sheet window attached to the message, allows you to select the name, click ok, and it populates the To: field.

In the Camino nightly build listed above, it appears as a seperate window, allows you to choose the name, but does not populate the To: field. 
No errors appear.

Reproducible: Always

Steps to Reproduce:
1.In a Notes message, type a partial name in the To: field
2. Click send
2. Choose the name in the Ambiguous Name window that appears 
3.Click OK 

Actual Results:  
The partial name still resides in the To: field

Expected Results:  
The full lotus notes name should be inserted.

Domino web access 7 is still in testing for Mac, currently only officially supports Firefox 1.5.02+

Comment 1

[Samuel Sidler (old account; do not CC)]

Does it work in the corresponding Bon Echo (Firefox 2 alpha) nightly?

You're testing with a Camino build based on the 1.8 branch. To test something comparable to Firefox 1.5.0.2, you can try Camino 1.0 or a nightly build based on the 1.8.0 branch (which is different than the 1.8 branch).

Comment 2

[Scott]

Attachment: Screenshots of the Domino Web Access Amiguous Name screens in Camino (bug) or FireFox (works)

Comment 3

[Scott]

With the log javascript errors in Console option on, these are the only messages that occur near the same time of the problem:

2006-05-01 14:09:13.208 Camino[1354] JS error: [JavaScript Warning: "Error in parsing value for property 'font-size'.  Declaration dropped." {file: "http://notes2.buffalo.k12.ny.us/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_StyleSheet&l=en&gz&CR&MX&TS=20060110T190507,72Z&BS=G" line: 3079}]
2006-05-01 14:09:13.208 Camino[1354] JS error: [JavaScript Warning: "Error in parsing value for property 'vertical-align'.  Declaration dropped." {file: "http://notes2.buffalo.k12.ny.us/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_StyleSheet&l=en&gz&CR&MX&TS=20060110T190507,72Z&BS=G" line: 3243}]
2006-05-01 14:09:13.208 Camino[1354] JS error: [JavaScript Warning: "Error in parsing value for property 'vertical-align'.  Declaration dropped." {file: "http://notes2.buffalo.k12.ny.us/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_StyleSheet&l=en&gz&CR&MX&TS=20060110T190507,72Z&BS=G" line: 3249}]
2006-05-01 14:09:13.208 Camino[1354] JS error: [JavaScript Warning: "Error in parsing value for property 'vertical-align'.  Declaration dropped." {file: "http://notes2.buffalo.k12.ny.us/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_StyleSheet&l=en&gz&CR&MX&TS=20060110T190507,72Z&BS=G" line: 3251}]

Comment 4

[Samuel Sidler (old account; do not CC)]

*** This bug has been marked as a duplicate of 336092 ***

Comment 5

[Samuel Sidler (old account; do not CC)]

Whoops...

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It's not really a sheet because it has the (same) status bar at the bottom; it's a web-content window that has been cleverly positioned in Firefox, according to your screenshot.

Scott, can you try this again with Camino 1.0 spoofing as Firefox 1.5.0.2?  I expect this is a TE issue where Camino is being given a random JS codepath whereas Firefox is being given a JS codepath specifically tailored and tested to work with Gecko....  (I'm most concerned with the field population; the appearance is minor, and we may not allow titlebar-less windows in Camino anyway.)

Comment 7

[Scott]

(In reply to comment #1)
> Does it work in the corresponding Bon Echo (Firefox 2 alpha) nightly?
> 
> You're testing with a Camino build based on the 1.8 branch. To test something
> comparable to Firefox 1.5.0.2, you can try Camino 1.0 or a nightly build based
> on the 1.8.0 branch (which is different than the 1.8 branch).
> 
Bon Echo worked fine- like FF1.5.02.

Camino 1.0 had the same problem FF 1.5.01 had- when you create a new message, the text field for the message body never finishes loading- and the status bar has a Transferring data from.... message

I'm not sure how to get a 1.8.0 branch- it's a bit perplexing for someone looking at it for the first time.  Camino Knight seems to grab 1.8 based, if the rv:1.8 in the user agent string  is what we're looking at. How do I tell for sure what branch?

Comment 8

[Samuel Sidler (old account; do not CC)]

This sounds like it might be an XUL-based interface.

When you View Source, does it show a typical HTML file with <html> at the top and <head> and <body> tags?

Comment 9

[Scott]

(In reply to comment #8)
> This sounds like it might be an XUL-based interface.
> 
> When you View Source, does it show a typical HTML file with <html> at the top
> and <head> and <body> tags?
> 

Here's  the source for the ambiguous name window:
<!-- (c) Copyright 1985-2005 IBM Corporation. All rights reserved. -->
<!-- $HaikuForm - 245 -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><title>Ambiguous Name</title> 
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta http-equiv="Content-Script-Type" content="text/javascript; charset=ISO-8859-1" /> 
<!-- Domino Release 7.0.1 (Windows NT/Intel) -->
<script>var h_PageUnid="D304E9E02C3C60FF85256981007A3185", h_PDCheck='<a href="/">x</a>',haiku={sFormsTLM:'20060110T190507,72Z',aCompressible:'1,1,1,1'.split(',')},s_FF='/iNotes/Forms7.nsf';</script>
<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_MinUtils&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1"></script>
<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=menucode&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1&ua=gecko"></script>
<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=qpbase&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1&ua=gecko"></script>
<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=qpbase2&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1&ua=gecko"></script>

<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=qpbase3&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1"></script>
<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=qpread&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1&ua=gecko"></script>
<script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=qpread2&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1"></script>
<script src="/mail/snourse.nsf/iNotes/Proxy/?OpenDocument&Form=s_SessionInfo&l=en&gz&MX&TS=20060501T170042,48Z&KIC&UNH=ga3mecvuk6lq5m8qq62ng9lrsq8&charset=ISO-8859-1"></script>
<link rel="stylesheet" type="text/css" href="/mail/snourse.nsf/iNotes/Proxy/?OpenDocument&Form=s_StyleSheet&l=en&gz&CR&MX&TS=20060110T190507,72Z&BS=G" /> <xml id="chkSess"></xml><script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_ValidationConfirmDlgCode_Init&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1"></script><script>var HTTP_COOKIE='Shimmer=SSI_TLM:20060501T170042%2C48Z&ST_Counter:3&OSCZ:Z%3D0%24DO%3D0%24ZN%3DGreenwich&DNIDate:20060501&CalIDate:20060501&PSLP:1&AMActive:1&CSDT:-157243&NMTLP:20060501T233035Z; LtpaToken=AAECAzQ0NTY5OTY2NDQ1NkE3NzZDTj1TY290dCBOb3Vyc2UvT1U9VGVhY2hlcnMvT1U9QnVmZmFsby9PPUVyaWUxj04sZkehfPeeNojEwh+cDJ2lZgg=; ShimmerS=ET:20060502T002734%2c00Z&R:0&AT:M';
var HTTP_USER_AGENT='Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4';
var PATH_INFO='/mail/snourse.nsf/iNotes/Proxy/?EditDocument&Form=s_ValidationDlg&Presetfields=s_Limited;1';
var QUERY_STRING='EditDocument&Form=s_ValidationDlg&Presetfields=s_Limited;1',s_BrowserSuffix='',s_Gecko='1',s_Safari='0',s_Accessible='0',s_Charset='ISO-8859-1',s_UAName='gecko';
var s_UNH='ga3mecvuk6lq5m8qq62ng9lrsq8',H_SYSTEMNAME='Proxy',s_ValId='',s_Limited='1';
var h_Context_InFolder = 0;var h_IsServerRegistered=0;
var h_BuildNumber='700000.00';
var h_MaxFileSizeAllowedToUpload = '50000';
</script><script src="/iNotes/Forms7.nsf/iNotes/Proxy/?OpenDocument&Form=s_DWASelect&l=en&gz&CR&MX&TS=20060110T190507,72Z&charset=ISO-8859-1"

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Scott, grab http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2006-04-27-04-1.0.1/

This is the Camino 1.0.1 release candidate, which should be functionally equivalent to Firefox 1.5.0.3 (forthcoming this week).  We can also find a build that's more equivalent to Firefox 1.5.0.2 if we need to....

This *almost* sounds like something that was broken in Gecko 1.8.0.1 and fixed in Gecko 1.8.0.2, thus the min version of Firefox 1.5.0.2 they require....  It seems like there could be a lot of branch issues, so we need to be careful here.

1.8.0 branch (rv: 1.8.0.x) = Firefox 1.5.0.x = Camino 1.0.x 
1.8.1 branch (rv: 1.8.1) = BonEcho 2.0 Alpha = Camino 1.0+ (the "nightly" link on caminobrowser.org)
Trunk (rv: 1.9a1) = Minefield 3.0a1 = Camino 1.2+

Comment 11

[Scott]

(In reply to comment #10)
> Scott, grab
> http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2006-04-27-04-1.0.1/
> 
> This is the Camino 1.0.1 release candidate, which should be functionally
> equivalent to Firefox 1.5.0.3 (forthcoming this week).  We can also find a
> build that's more equivalent to Firefox 1.5.0.2 if we need to....
> 
> This *almost* sounds like something that was broken in Gecko 1.8.0.1 and fixed
> in Gecko 1.8.0.2, thus the min version of Firefox 1.5.0.2 they require....  It
> seems like there could be a lot of branch issues, so we need to be careful
> here.
> 
> 1.8.0 branch (rv: 1.8.0.x) = Firefox 1.5.0.x = Camino 1.0.x 
> 1.8.1 branch (rv: 1.8.1) = BonEcho 2.0 Alpha = Camino 1.0+ (the "nightly" link
> on caminobrowser.org)
> Trunk (rv: 1.9a1) = Minefield 3.0a1 = Camino 1.2+
> 

Camino still has the same issues with the ambiguous name widget.  There are also similarly acting widgets for the Move button (but not the menu) and the Follow Up button (but not the menu).  So, all of these issues have workarounds, but make it more difficult for the end user to use Camino for notes web access. (sigh- it's SUCH a nice browser)

Oddly, Domino Web Access on FireFox 1.5.03 for windows does NOT use the psuedo-sheet windows for these widgets.  They open in a seperate window (like Camino) but do as is expected.  Weird.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #11)
> Camino still has the same issues with the ambiguous name widget.

Identifying as Camino, correct?  

And if you have that very same Camino spoof as Firefox 1.5.0.3 (http://www.caminobrowser.org/support/hiddenprefs/#SpoofUserAgent), what happens?

Comment 13

[Scott]

(In reply to comment #12)
> (In reply to comment #11)
> > Camino still has the same issues with the ambiguous name widget.
> 
> Identifying as Camino, correct?  
> 
> And if you have that very same Camino spoof as Firefox 1.5.0.3
> (http://www.caminobrowser.org/support/hiddenprefs/#SpoofUserAgent), what
> happens?
> 

There's no change using the useragent setting : user_pref("general.useragent.override", "Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3");

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Is this still a problem with Camino 1.1 Beta?  With a fresh profile?

Comment 15

[Chris Lawson (gone)]

...or with Camino 1.5?

I'm going to close this INCOMPLETE. If anyone can provide more information about the problem, feel free to re-open.

Comment 16

[Scott]

Nope- still there with Camino 1.5/fresh profile, plus we've got the latest update for the Lotus Notes 7 server/profiles....

Comment 17

[Scott]

I think that they are using XUL as noted above. As I understand it- this will not be on option in Camino, correct?  

The interface issues that result usually have a workaround (except for creating a new folder).  There's just enough wrong to NOT support Camino as a Notes e-mail client browser for users in general.

Performance, however, is really VERY good in all other aspects of the Notes Webmail client.  I prefer Camino for general mail browsing.

I think it would be up to the Lotus Notes team to have a workaround for non-Firefox browsers on those few interface elements. If there's any interaction between IBM's domino/Notes team and Mozilla perhaps this could be brought up?

Thanks for looking into it.. and keep up the excellent work.

Comment 18

[Samuel Sidler (old account; do not CC)]

(In reply to comment #17)
> I think that they are using XUL as noted above.

That would make this a dupe of bug 306252, probably.

Comment 19

[Chris Lawson (gone)]

Camino does not use XUL for its interface, but (in theory) should support XUL elements in the content area. That it doesn't is likely the bug Sam mentioned in this case. Is there any way you can track down the source of the various JavaScript files linked in comment 9, or confirm whether you see <menulist> or <menupopup> as part of the interface?

http://xulplanet.com/tutorials/xultu/examples/ex_lists_5.xul

has a couple examples of what these elements might look like.

Reopening for now, pending an answer to the above.

Comment 20

[Scott]

Attachment: JavaScript files from Lotus Note Ambiguous Name sheet

Here are the javascripts requested from the Ambiguous Name window

Comment 21

[Chris Lawson (gone)]

(In reply to comment #20)
> Created an attachment (id=267605) [details]
> JavaScript files from Lotus Note Ambiguous Name sheet

I looked through all these files and didn't see anything resembling XUL elements, but I suppose I could have missed something.

If someone can confirm that Domino does indeed use XUL for its interface, we can probably safely dupe this over to bug 306252 and call it good, because it's quite possible those files didn't capture the interface elements in question.

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Confirming; I can, after great pains, reproduce this at Lotus's demo site.

Username: Camino Browser
Password: test1camino
Mail URL: http://showcase2.notes.net

This is user is valid for one week, but you can create new accounts at any time at https://showcase2.notes.net/inreg.nsf/regform (per the demo description)

Dismiss the million zillion trillion CAPS warning sheets that come up asking for advanced script permissions (if you deny them all, the Ambiguous Name thing will not appear, so you need to allow at least the one(s) when creating a new mail message and after pushing the little yellow resolve name button).  Don't dally too long on any CAPS sheet or the sheet will become stuck forever.

Create a new mail message; type anything into the To: field.  The little yellow button appears to the left of the field.  Click it.  Allow the CAPS stuff, and show the pop-up.

As Scott's screenshot illustrates, in Firefox this popup is a titlebarless, toolbarless window positioned like a sheet on the message.  In Camino, we get a window with a titlebar, and it's positioned off-center randomly.

I suspect there are a couple of bugs here, one being the lack of titlebarless window support, and one being the popup's javascript not being able to talk back to the window that actually spawned it (or somesuch; you know the extent of my JS knowledge ;) ).  Hopefully this is now enough to let someone who does know JS start investigating.  With any luck it might even be onbeforeunload :p

Scott, thanks for having patience with us on this one.

(Note also that this is vanilla HTML and JS, more or less, and they seem to be intelligent enough to set up their codepaths for "Gecko" and not "Firefox" :) )

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I wonder if this is another XPT-related bug, too, or if it's really something bigger?

Comment 24

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Scott, can you check in Camino 1.5.4 and see if this is still broken?  We fixed some things that caused random content breakages, and it's possible that this might have fixed this bug.

I can jump through the hoops in comment 22 again if needed, but you're far more familiar with how this is supposed to work ;)

Comment 25

[Scott]

Smokey, unfortunately we appear to now have an issue that has cropped up in the most recent Firefox releases- There is an error message (after a long pause) in Camino after typing in a partial name and clicking send:
>>
Domino Web Access Warning. Sorry, we were unable to process your request at this time. If you are unable to continue working in your mail file, please dismiss this warning and then select View, Reload from your browser's menu.
<<

This message appears now in Firefox 2..0.0.11 (and possibly .10) when first bringing up the mail view, but doesn't happen on the partial name-- in Firefox it NEVER brings up any selection box OR error message.

I believe it's related to this thread: 
http://www-10.lotus.com/ldd/nd8forum.nsf/DateAllThreadedWeb/16d421d97b933458852573a2005eca9f?OpenDocument

Our help desk has requested Mac users use the old web view in Safari for the time being.

Comment 26

[Scott]

Also found:

http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/eaf3a4852721816e852573a100476ec4?OpenDocument

Although I'm not sure it's the same issue

Comment 27

[Scott]

The security issue was fixed via a server update- it looked the new Firefox/Camino security fixes required a fix on the Domino server.

Now that I can login it appears that bug for the Ambiguous Name field still occurs under  Camino 1.5.4.  

Thanks for looking into it.

Comment 28

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]