[Rod Paine]

The ability to use OmniWeb above sp1 to edit web pages hosted by Verizon is still broken. All you get are pages of html code, not browser style pages with edit box commands to edit the pages using a GUI. OmniWeb 5.1.3 and prior versions don't do this. Can't this be fixed?
-Rod

[Forrest]

Does it work in WebKit?

[Rod Paine]

Originally Posted by Forrest

Does it work in WebKit?

No, it doesn't. No Mac browser now works in the Verizon/Trellix web page editing environment. You have to use a PC with Explorer, Firefox or Opera if don't want to be forced to work with html only. Pretty sad state for Mac owners who don't know how, or don't want to learn how to use html. This is progress for the end user?
-Rod

Background
This has been an issue with Mac browsers since January of this year, when I first posted this report on MacInTouch and sent a copy to OmniWeb:

Name: Rod Paine
Date: 1/3/06
Subject: Verizon Web Page Creation Tool

Verizon's web page tool, "Trellix SiteBuilder" is a fairly decent web page creation tool for those of us using PCs, but using it with current Mac OS X and various Mac browsers, it appears that only one Mac web browser displays the Trellix creation pages the same way Windows XP and Internet Explorer does and that's by using OmniWeb 5.1.3b2. Otherwise, the Trellix page is not a combination of graphics and text blocks, but simply html code. Hardly supportive of the new Verizon DSL customer, using a Mac and attempting to create a web site, with no html experience at all.

I've recently tried Trellix under Mac OS X 10.4.3 using Firefox 1.5, Deer Park, Camino 1.0b2, iCab 3.0.3b, Opera 8.51, Safari 2.0.2, IE 5.2.3 and Netscape 7.2, all of which exhibit this Trellix display problem when attempting to create or edit a web page. Use OmniWeb 5.1.3b2, so that you can see the intended web page creation interface and not simply html code. HTH.

[Rod Paine]

Originally Posted by Rod Paine

The ability to use OmniWeb above sp1 to edit web pages hosted by Verizon is still broken. All you get are pages of html code, not browser style pages with edit box commands to edit the pages using a GUI. OmniWeb 5.1.3 and prior versions don't do this. Can't this be fixed?
-Rod

sp12 exhibits the same problem, it doesn't work in the Verizon/Trellix web page editing environment.
-Rod

[Rod Paine]

Originally Posted by Rod Paine

rc1 exhibits the same problem, it doesn't work in the Verizon/Trellix web page editing environment.
-Rod

It looks like you're going to release a product that still can't handle Verizon hosted web page construction and editing, which last functioned properly in OmniWeb 5.1.3, that I have been reporting ever since. Evidently you feel that perhaps I am the only person who uses their Verizon DSL account web page service? Shame on you.
-Rod

[JKT]

1. Why pay money to Verizon when they aren't providing you with a complete service for your money and evidently have zero intention of doing so?

2. By upgrading to WebKit in OmniWeb 5.5, compatibility with more sites will be fixed than will be broken. Yours is just one example of a broken site that evidently isn't used by too many people who also use OmniWeb or Safari or any other Mac browser. Fixing the compatibility with those other sites which are used by more people is more important.

3. Does the version of WebKit that OmniWeb 5.5 is based on have the same problem? Does the latest nightly build? If it is fixed in the latest nightly build, then the problem should also be fixed in 5.5.1. If it is working in the equivalent WebKit build to that in 5.5 but not in 5.5 itself then it is a bug that needs fixing in OmniWeb.

4. Does identifying to the site as IE6 for Windows fix the problem at all?

5. You can run OmniWeb 5.1.3 in parallel with 5.5 if you have to, until the fix finds its way into WebKit. That is, just for this one site, you can use 5.1.3 in place of 5.5.

6. If it works in Firefox or Opera on the PC it should work in Firefox or Opera on the Mac. If it doesn't then there is definitely something weird happening and Verizon is specifically blocking Mac users for no good reason.


7. Thus, once again, why pay money to Verizon when they aren't providing you with a complete service for your money and evidently have zero intention of doing so?

[Len Case]

Hi Rod,

This actually sounds like a server configuration problem where they declare html pages to be text instead and the various mac browsers believe them.

Perhaps we can add a preference to ignore the server specified mimetype.

You could check this in OmniWeb (5.1.3 or 5.5) by opening the Error Log (Command-Shift-L) and turning on "Show http requests". Look at the responses and see what "Content-Type" the server returns.

[Rod Paine]

Originally Posted by JKT

1. Why pay money to Verizon when they aren't providing you with a complete service for your money and evidently have zero intention of doing so?

2. By upgrading to WebKit in OmniWeb 5.5, compatibility with more sites will be fixed than will be broken. Yours is just one example of a broken site that evidently isn't used by too many people who also use OmniWeb or Safari or any other Mac browser. Fixing the compatibility with those other sites which are used by more people is more important.

Verizon provides web page hosting via Trellix as part of my basic 3Mbps/768kbps DSL service. It is not an additional cost item.

It is not my web site that is broken, it is the Verizon web page creation tool and maintenance html interface that OmniWeb does not display correctly! It appears you don't understand the problem, and/or have no experience with the Verizon web page creation and host service. It is my understanding that there are several million people using this service, but most all of them are using the Windows OS.
-Rod

[Rod Paine]

Originally Posted by Len Case

Hi Rod,

This actually sounds like a server configuration problem where they declare html pages to be text instead and the various mac browsers believe them.

Perhaps we can add a preference to ignore the server specified mimetype.

You could check this in OmniWeb (5.1.3 or 5.5) by opening the Error Log (Command-Shift-L) and turning on "Show http requests". Look at the responses and see what "Content-Type" the server returns.

Len,
Does this give you a clue?

2006-08-31 06:16:10 Rx <http://sitebuilder.verizon.net/trellix/sitebuilder/f_edit_page.html>
2006-08-31 06:16:10 Rx Status: 200 no error
2006-08-31 06:16:10 Rx Headers:
{
Connection = "Keep-Alive";
"Content-Length" = 2340;
"Content-Type" = "text/html";
Date = "Wed, 30 Aug 2006 00:11:57 GMT";
"Keep-Alive" = "timeout=15, max=100";
"Last-Modified" = "Fri, 24 Oct 2003 14:57:03 GMT";
Server = "Tomcat Web Server/3.3.1 Final ( JSP 1.1; Servlet 2.2 )";
"X-Cache" = "MISS from sitebuilder.verizon.net";
}
There is a lot of other stuff, none of which I understand, since I don't work with html. I would add that the pages that the Trellix system creates appears to have a lot of errors, as reported by browsers that can do this, or an html validation tool. Trellix has no comment about this, other than to say "millions are using their software without problems."
HTH,
-Rod

[Len Case]

Originally Posted by Rod Paine

Len,
Does this give you a clue?

[...]
"Content-Type" = "text/html";
[...]

Sadly, the content type header looks correct so that is not the likely source of the problem.