Closed Bug 23495 Opened 25 years ago Closed 8 days ago

need ability to identify Composer vs Navigator using the UA string

Categories

(Core :: DOM: Editor, defect, P5)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: geoff, Unassigned)

References

Details

Currently (4.x, M12?) there is no way to differentiate between a GET request
from Composer and a GET request from Navigator. This effectively disables our
web content managment system from being able to do smart things when it detects
a GET which may then result in a PUT, (eg an "Edit" operation rather than
a "View" operation).
Can this please be added (should be pretty easy?)
NOTE: Charlie Manske told be to report under NetLib, closest I could see was
Networking, hope this is right...
Could you be more elaborate? I don't understand how identifying Composer's GET
request separately would help in general? An "Edit operation" doesn't
necessarily indicate that it will be followed by a PUT and why would you want to
distinguish between the two(composer/nav)? Cc'ing valeski.
Target Milestone: M15
Not sure this request is valid, since navigator/composer are really one
application, and it's difficult to know when a request is being made by one vs.
the other.
ok, here's a scenario: I have a web app that helps users to edit web pages.
when they open a page to edit in navigator, I want to dynamically generate a
toolbar for my app. when they open a page in composer, I want to suppress the
generation of the toolbar. Currently I can't do this, because there is no way
to differentiate between a GET from Navigator and a GET from Composer. They are
different apps from user perspective: they should have a different UA string!
I do think that it might be useful to be able to distinguish Composer, Mail, and 
Navigator requests (and others?).

On the other hand, I would hate to see someone deny "editing" while serving the 
browser.  Then again, maybe that would be a good thing (handoff different 
documents or enable/disable functionality based on where the request is coming 
from).  I think this is something like what geoff wants to do.
->valeski our Secret User Agent...
Assignee: gagan → valeski
*** Bug 29968 has been marked as a duplicate of this bug. ***
Adding Bijal Shah, Composer PM, to the cc: list, as I don't really understand 
this or have time to investigate this question myself.
assigning to bijals. Composer needs to figure out how they want themselves
represented in the UA string. We're naturally going to want to add a new product
token for them, however that will start us down our nice "everyone" wants their
own product token slipery slope... What did 4.x do? Also, this would mean that
the user agent should be something set by whoever's initiating the request
(pain). Mail/news is using the general HTTP user agent in their headers.
Assignee: valeski → bijals
This does not appear to be an M15 stability blocker, so I'm now pushing this to 
M16.
Target Milestone: M15 → M16
Status: NEW → ASSIGNED
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Move to M18 post PR2
Target Milestone: M16 → M18
Nice to have, but not for Seamonkey release so setting to futures.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Target Milestone: M18 → Future
reopen bug so it doesn't get lost; milestone Future should be sufficient
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
mass move, v2.
qa to me.
QA Contact: tever → benc
-> editor, qa to default.
btw, assignie needs to be updated.
Component: Networking → Editor
QA Contact: benc → sujay
-> kin@netscape.com
Assignee: bijals → kin
Status: REOPENED → NEW
QA Contact: sujay → editor
Assignee: kinmoz → nobody

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5

The very original request was for SeaMonkey. WONTFIX from Firefox/Gecko point of view.

Status: NEW → RESOLVED
Closed: 24 years ago8 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.